responding to http://www.electrondepot.com/embedded/siemens-sab-80c537-reverse-engineering-43397-.htm , gldiana wrote:> blockedofcourse wrote: > > On 6/9/2016 6:37 PM, Gian Luigi wrote: > > > The turbine brand is "Windworld". The PLC brand > (manifacturer) is "Sentic", > > model name is "convoy 537" ( known also as "Mark > IV"). > > Sentic is no longer existing: the turbine was sold originally in > 1992, and if > > you google "sentic controller" you will find almost > nothing. That is more a > > controller than a PLC, in the sense that it has been tailor made > for this > > application only... > > Ah. > > > I know that in the eprom there's binary code, but I am not able to > disassemble > > it without your help. > > Given the choice of a 64KB device, it is likely that at least half of it > > is used (else a 32KB device could have been used at reduced cost). > That's a fair bit of code to "reverse engineer" -- esp if you > have no > *definitive* idea what the interfaces are like (which signals are > present > on which inputs, what the balance of the electronics do on the board, > etc.) > > This is the sort of thing that falls in the "hobbyist" > category -- someone > with more interest/time than money (it would cost you a fair bit to have > > the design reverse engineered). > > [I've known folks who hand-disassembled ~48KB binaries "out of > curiosity" > but knew, up front, that it was an uneconomical task and did it for the > "personal challenge"] > > Your comments suggest there's a servo/control loop operating to keep > the turbine at (or "not to exceed"?) a particular speed. > (how?) > > If that's the case, then you might find it easier to *trick* the > controller > into doing what you want: > - tells the MCU the current rotor rpm > - the MCU actuates to drive the rpm as desired > So, if the current RPM setting is "hard coded" as X and you > want it > to be Y, figure out how to introduce a X/Y scale factor in the > *sensed* RPM. In this way, when the motor RPM *is* Y, the MCU > will see it as Y * X/Y = X and think it is doing exactly what it > was designed to do! > > Alternatively, introduce a Y/X factor in the actuator output... > > [There are lots of assumptions in this -- any of which can make it > an inappropriate solution. But, I don't know what your system does > or how it operates so can't identify those risks] > > > Finally I would say that I know exactly what I am going to do > modifying that > > parameter.. > > > > I have also a photo of that plc: is there any way to attach it > here? > > No. You could post it to a hosting site and pass a pointer (URL) > in a followup post, here. But, hard to say much of anything even > from a photo... > >Don Y, thank you alot for your answer. The controller needs to check the rotor rpm because when it reaches a set value it has to connect the generator to the grid and start electricity production. I add that I do have all electrical schemes and data sheets af all devices connected with the controller, so I know pin assignment of all analog and digital I/O. Originally it is made with two proximity sensors that produce a pulse when two masses located on the brake disk pass in front of them (sensors are mounted on fixed frame, masses are installed on brake disk and rotate with it) ... So the controller should measure the time between two pulses (when the pulses of both sensors are "on" at same time) and calculate the rpm. How can I "fool" the controller "translating" the sensors signal? To me seems that the only way is to have a wheel rotating at "original" rpm, with two similar proximity sensors, and connect it to the controller when the rotor is rotating at new "rpm".. And in this case I need to read the actual rotor rpm to manage the system... Indeed the "fooling" system should give a proportional rpm signal to controller at any time to let it keep all safety controls based on rpm check working.. The other way round is viable only if I am able to find an editor of the eprom but at a level far higher than assembler level... For sure I cannot deal with machine-level instructions.. Do you have any other ideas?? --
Re: Siemens SAB 80C537 Reverse Engineering
Started by ●June 10, 2016
Reply by ●June 10, 20162016-06-10
On 2016-06-10 gldiana wrote in comp.arch.embedded:> responding to > http://www.electrondepot.com/embedded/siemens-sab-80c537-reverse-engineering-43397-.htm > , gldiana wrote: >> blockedofcourse wrote: >> >> On 6/9/2016 6:37 PM, Gian Luigi wrote: >> >> > The turbine brand is "Windworld". The PLC brand >> (manifacturer) is "Sentic", >> > model name is "convoy 537" ( known also as "Mark >> IV"). >> > Sentic is no longer existing: the turbine was sold originally in >> 1992, and if >> > you google "sentic controller" you will find almost >> nothing. That is more a >> > controller than a PLC, in the sense that it has been tailor made >> for this >> > application only... >> >> Ah. >> >> > I know that in the eprom there's binary code, but I am not able to >> disassemble >> > it without your help. >> >> Given the choice of a 64KB device, it is likely that at least half of it >> >> is used (else a 32KB device could have been used at reduced cost). >> That's a fair bit of code to "reverse engineer" -- esp if you >> have no >> *definitive* idea what the interfaces are like (which signals are >> present >> on which inputs, what the balance of the electronics do on the board, >> etc.) >> >> This is the sort of thing that falls in the "hobbyist" >> category -- someone >> with more interest/time than money (it would cost you a fair bit to have >> >> the design reverse engineered). >> >> [I've known folks who hand-disassembled ~48KB binaries "out of >> curiosity" >> but knew, up front, that it was an uneconomical task and did it for the >> "personal challenge"] >> >> Your comments suggest there's a servo/control loop operating to keep >> the turbine at (or "not to exceed"?) a particular speed. >> (how?) >> >> If that's the case, then you might find it easier to *trick* the >> controller >> into doing what you want: >> - tells the MCU the current rotor rpm >> - the MCU actuates to drive the rpm as desired >> So, if the current RPM setting is "hard coded" as X and you >> want it >> to be Y, figure out how to introduce a X/Y scale factor in the >> *sensed* RPM. In this way, when the motor RPM *is* Y, the MCU >> will see it as Y * X/Y = X and think it is doing exactly what it >> was designed to do! >> >> Alternatively, introduce a Y/X factor in the actuator output... >> >> [There are lots of assumptions in this -- any of which can make it >> an inappropriate solution. But, I don't know what your system does >> or how it operates so can't identify those risks] >> >> > Finally I would say that I know exactly what I am going to do >> modifying that >> > parameter.. >> > >> > I have also a photo of that plc: is there any way to attach it >> here? >> >> No. You could post it to a hosting site and pass a pointer (URL) >> in a followup post, here. But, hard to say much of anything even >> from a photo... >> >> > Don Y, thank you alot for your answer. > > The controller needs to check the rotor rpm because when it reaches a set > value it has to connect the generator to the grid and start electricity > production. I add that I do have all electrical schemes and data sheets af all > devices connected with the controller, so I know pin assignment of all analog > and digital I/O. > > Originally it is made with two proximity sensors that produce a pulse when two > masses located on the brake disk pass in front of them (sensors are mounted on > fixed frame, masses are installed on brake disk and rotate with it) ... So the > controller should measure the time between two pulses (when the pulses of both > sensors are "on" at same time) and calculate the rpm. > > How can I "fool" the controller "translating" the sensors signal? To me seems > that the only way is to have a wheel rotating at "original" rpm, with two > similar proximity sensors, and connect it to the controller when the rotor is > rotating at new "rpm".. And in this case I need to read the actual rotor rpm > to manage the system... Indeed the "fooling" system should give a proportional > rpm signal to controller at any time to let it keep all safety controls based > on rpm check working..If you are a mechanical guy, you could solve it with a second wheel. And if you drive that wheel with gears or belt from the original, you set the translation ratio with the gear ratio.> The other way round is viable only if I am able to find an editor of the eprom > but at a level far higher than assembler level... For sure I cannot deal with > machine-level instructions.. > > Do you have any other ideas??The electronic version of the gears would be to insert a box in the proximity sensor lines. This box determines the speed from the sensors and outputs a translated version of the signals to the controller. This fools the controller into believing the rotor rotates at a different speed, just as the mechanical solution. Introducing any kind of translation will change the operating parameters of the system. This may result in less optimal regulation. Especially in the electronic version, make sure you don't introduce (too much) delay is the speed sensing. How much of a change in rpm are you looking for? Is the turbine suited to run at the 'new' rpm? -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Satire does not look pretty upon a tombstone.
Reply by ●June 10, 20162016-06-10
On 6/10/2016 8:20 AM, Stef wrote:>> The controller needs to check the rotor rpm because when it reaches a set >> value it has to connect the generator to the grid and start electricityOK. So, now you want to connect it "sooner" -- or "later"? (lower rpm or higher) Why? What's wrong with letting it work "as is"? How will the generator perform in this new operating condition?>> production. I add that I do have all electrical schemes and data sheets af all >> devices connected with the controller, so I know pin assignment of all analog >> and digital I/O. >> >> Originally it is made with two proximity sensors that produce a pulse when two >> masses located on the brake disk pass in front of them (sensors are mounted on >> fixed frame, masses are installed on brake disk and rotate with it) ... So the >> controller should measure the time between two pulses (when the pulses of both >> sensors are "on" at same time) and calculate the rpm. >> >> How can I "fool" the controller "translating" the sensors signal? To me seems >> that the only way is to have a wheel rotating at "original" rpm, with two >> similar proximity sensors, and connect it to the controller when the rotor is >> rotating at new "rpm".. And in this case I need to read the actual rotor rpm >> to manage the system... Indeed the "fooling" system should give a proportional >> rpm signal to controller at any time to let it keep all safety controls based >> on rpm check working.. > > If you are a mechanical guy, you could solve it with a second wheel. And if > you drive that wheel with gears or belt from the original, you set the > translation ratio with the gear ratio.This would be the easiest to implement and be assured of "correctness", IMO. But, I have no idea what the mechanism looks like so can't comment on how practical it would be to add/alter gearing off the rotor shaft -- or ANY OTHER PLACE INDIRECTLY DRIVEN BY IT (i.e., if there is a point that is already spinning at twice the rotor shaft speed, then placing the sensors there would give you a 2:1 ratio; similarly, if you can find a spot rotating at 47:29, that would provide a 47:29 ratio...) Note that if you are looking for 2:1, you might be able to just add more "masses" on the brake disk -- so the sensors think the original 2 masses (now replaced by 4) are passing by twice as fast. Again, hard to say what options are practical without seeing the mechanism. *Or* knowing what ratio is desired! (e.g., 1.9463825 might be hard to achieve, mechanically :> )>> The other way round is viable only if I am able to find an editor of the eprom >> but at a level far higher than assembler level... For sure I cannot deal with >> machine-level instructions..Then, in all probability, you are out of luck. For this to be even remotely possible, the controller would have had to have been *developed* in some "higher than assembler" means. And, you would have to know what that was. Finally, you would have to find a tool that can disassemble the EPROM binary and then "decompile" the resulting assembly language into the higher level representation. The human brain is typically used to do this -- in a very manual process (by recognizing what the code appears to be doing and adding commentary to it to explain this to others)>> Do you have any other ideas?? > > The electronic version of the gears would be to insert a box in the proximity > sensor lines. This box determines the speed from the sensors and outputs a > translated version of the signals to the controller. This fools the controller > into believing the rotor rotates at a different speed, just as the mechanical > solution.As electronics/software are considerably easier for me to implement (I don't have to machine any blocks of metal, cut any gears, mount anything on an existing framework, etc.), this is the approach I would follow. The risk here is that you will introduce a lag between the actual mechanism and the "synthetic mechanism". This can alter the tuning of the controller if it does anything besides just "engage the generator". In essence, you build two virtual mechanisms: - one that looks at the existing sensors to determine the current speed (by measuring the time between sensed events or frequency of events and relating that to the actual corresponding rotor motion -- N pulses is one revolution taking place in some time, T) - another that listens to the first and *synthesizes* an appropriate number of pulses faster/slower (depending on the desired overall ratio) that are injected (electronically) into the controller (which no longer is connected to the original sensors)> Introducing any kind of translation will change the operating parameters > of the system. This may result in less optimal regulation. Especially > in the electronic version, make sure you don't introduce (too much) delay > is the speed sensing. > > How much of a change in rpm are you looking for? Is the turbine suited to > run at the 'new' rpm?+1 on both questions And, how critical is that "exact" figure? E.g., if you are looking for a 10% change, would 8% be OK? What about 15%?
