On-Line, Real-Time, Programming...

[Clay B.]

Confused

I come from A Ti background. 5TI, 520C, 545, 300 series.

This is all I know for sure a TI 545 is a direct replacemnt for a Siemens 545.

I know the developers from the TI 300 series created the Automatin Direct PLC line. I know this because I needed to convert a obsolete TI 305 to an AD 305 and worked with these guys to get it done.

Now the assumptions I made. Due to the chassy design of the S5 I assumed it was an evolution of the 545. I also assumed that STL was created for the Euro market due to only seeing it used on European built machines.

So my question is. Did Satan really invent STL?

 

[Peter Nachtwey]

Wow, such fun! I must join in.

If anyone has every seen the original programming software, MicroDos, for a S7-200 then you KNOW without a doubt that the programming software was copied from the old TIsoft. Who actually wrote it I don't know, and don't care. It is not a religious issue with me like it is for some on this forum.

The idea of putting a PPI port on the S7-200 had to be a Siemens brain dead idea. [rant] I detest non standard communications [/rant] Previous TI designs used serial ports. I would have used RS-485 but that is all in the past now.

Why would TI suddenly introduce STL into the S7-200? Previous TI designs did not have STL or low level programming. The Koyo designs ( TI305, TI405) could show their rung in a STL like manner but then these are Koyo designs not TI. Evidence points to Siemens putting a lot of constraints on the former TI engineers or the S7-200 was largely developed by Siemens.

What is odd is that the STL is different between the S7-200 and the S7-300. This does appear to me a case of NIH or reinventing the wheel. Why develope another instruction set? Perhaps because the S7-200 was not going to use the S7-300 CPU? Instruction sets can be emulated. Interpreter are used on PLCs all the time. Some decision was made to keep the S7-200 and S7-300 separate. Why? Modicon has made a point of telling customers that you can program their smallest to largest PLC using one programming package.

My 'guess' is that the S7-200 was largely designed in Germany before Siemens bought out TI PLCs and the software, MicroDos, was written for it here to keep the former TI software engineers busy. MicroWin could have been written anywhere.

The amount of effort it takes to design the PLC is insignificant to the software effort required to program and support it. Who cares where the S7-200 was designed? It is not the hardware that gives a PLC its personality, it is the software.

Oh, everything a CPU does takes processing time. Monitoring, downloading code, swapping out this rung for that rung etc. It all takes time. I don't believe a S7-381 can swap out code without it impacting the scan time. You may need to look the scan time with a scope. You may also have a longest scan time register. What sets that?

 

[Clay B.]

Ok it's Saturday and not ****tail hour yet

The amount of effort it takes to design the PLC is insignificant to the software effort required to program and support it. Who cares where the S7-200 was designed? It is not the hardware that gives a PLC its personality, it is the software.

Ok I will bite. I do not totally disagree, but I do to a point. If the hardware deign is poor the best software in the world will not fix it. I believe (yes it is my religion) that hardware design is the biggest limiter to software design. My evidence, what we are talking on right now. It was advancements in hardware that allowed the interent to evolve into what it is now.

I joke about STL (though I am serious when I say really do not understand it) but I have seen the S5 in action and I find it to be a rugged PLC.

Am I wrong in my belief that the hardware drove this PLC to what it became?

 

[Terry Woods]

Stephen...

Regarding how to accomplish on-line programming... this has some holes in it, but...

I think the best way to make it happen is to have two duplicate memory areas. At any given time, one, or the other, is the Active Memory Area.

I would expect a single Processor for running the process, and a single I/O Table. That processor would use the code from the Active Memory Area.

There would have to be a separate processor for managing the content of the inactive memory area. That processor should probably also control which area is active.

You should have the ability to SAVE the content of the inactive area either before or after editing. Maybe there should be an automatic back-up function that occurs whenever, and just before, switching to the inactive memory area. This could be very helpful for undoing (back-tracking through) bad code changes that might have happened overnight.

There should be a version manager/tracker. You should be able to restore any saved copy to the inactive memory area.

Now, while in Edit-Mode, the Active Memory Area should be LOCKED ON as Active. When an edit is made... the edit applies only to the Inactive Memory Area. You can edit or create rungs, search, find-n-replace, cut-n-paste,... anything that you could normally do while editing off-line. All changes are written to the inactive memory area.

When you are ready... you simply activate the appropriate function to tell the PLC to switch to the new version. The first thing that happens is that the new code is SAVED to the PC. Then, at the appropriate time (just before the beginning of a scan), the Memory Area Processor switches the Active Flag to the other memory area.

Now, having switched to the new code, the previous version still resides in the other memory area. If you find that you are not satisfied with the results of the edits... you should be able to simply return to the previous version, still existing in the inactive area. Or... if you know what is wrong, you could restore the copy of the saved new code to the inactive area and make the necessary changes.

All of this activity should occur without affecting the scan-time of the currently running process.

Issues...

There would have to be a way to manage current Timer and Counter values. This is a tough one.

It would be great to be able to have the inactive area react to, at least, inputs and control relays - without affecting real outputs. This could be somewhat of a simulator.

Of course... On-Line programming is NOT for everyone. Just as with any programming, you have to KNOW what you are doing! If you don't know what you are doing, then it doesn't matter if you are On-Line or Off-Line... you're likely to break something, or hurt someone.

 

[S7Guy]

If anyone has every seen the original programming software, MicroDos, for a S7-200 then you KNOW without a doubt that the programming software was copied from the old TIsoft. Who actually wrote it I don't know, and don't care. It is not a religious issue with me like it is for some on this forum.....

Why would TI suddenly introduce STL into the S7-200? Previous TI designs did not have STL or low level programming. The Koyo designs ( TI305, TI405) could show their rung in a STL like manner but then these are Koyo designs not TI. Evidence points to Siemens putting a lot of constraints on the former TI engineers or the S7-200 was largely developed by Siemens.

I don't think it's a religious issue. I mean, we do this for a living, and it's natural to be curious about the history of the products we use. I'd still like to have some info on the predecessor of the S5 that I used.

Looking back to the far reaches of my memory, I think the S7-200 story went down like this: The processor was designed in Germany, but no one had time to develop a programming interface. The Johnson City guys were used to throw together MicroDos as a stop-gap measure until MicroWin was ready (I assume this was from Germany). I only know this because the first 200's I programmed were with MicroDos, and then I found out that the programs could not be converted to MicoWin, and I had to convert everything manually. My Siemens rep dug into it and explained the above to me.

Siemens has sort of a history like that. They don't seem to have a lot of overlap between development groups. For instance, take a look at ProTool. It really doesn't even have a Windows "feel". The help menus are not like Windows at all, nor is the menu structure. It doesn't even look like Step 7. All I can think of is that there were ProTool designers back in Germany doing their own thing with complete disregard to what everyone else in the world was doing.

On the other hand, Simatic Manager developers enlisted MicroSoft right from the beginning to make sure it had the Windows "feel". You can see the difference.

 

[Clay B.]

Stephen...

Regarding how to accomplish on-line programming... this has some holes in it, but...

I think the best way to make it happen is to have two duplicate memory areas. At any given time, one, or the other, is the Active Memory Area.

I would expect a single Processor for running the process, and a single I/O Table. That processor would use the code from the Active Memory Area.

There would have to be a separate processor for managing the content of the inactive memory area. That processor should probably also control which area is active.

You should have the ability to SAVE the content of the inactive area either before or after editing. Maybe there should be an automatic back-up function that occurs whenever, and just before, switching to the inactive memory area. This could be very helpful for undoing (back-tracking through) bad code changes that might have happened overnight.

There should be a version manager/tracker. You should be able to restore any saved copy to the inactive memory area.

Now, while in Edit-Mode, the Active Memory Area should be LOCKED ON as Active. When an edit is made... the edit applies only to the Inactive Memory Area. You can edit or create rungs, search, find-n-replace, cut-n-paste,... anything that you could normally do while editing off-line. All changes are written to the inactive memory area.

When you are ready... you simply activate the appropriate function to tell the PLC to switch to the new version. The first thing that happens is that the new code is SAVED to the PC. Then, at the appropriate time (just before the beginning of a scan), the Memory Area Processor switches the Active Flag to the other memory area.

Now, having switched to the new code, the previous version still resides in the other memory area. If you find that you are not satisfied with the results of the edits... you should be able to simply return to the previous version, still existing in the inactive area. Or... if you know what is wrong, you could restore the copy of the saved new code to the inactive area and make the necessary changes.

All of this activity should occur without affecting the scan-time of the currently running process.

Issues...

There would have to be a way to manage current Timer and Counter values. This is a tough one.

It would be great to be able to have the inactive area react to, at least, inputs and control relays - without affecting real outputs. This could be somewhat of a simulator.

Of course... On-Line programming is NOT for everyone. Just as with any programming, you have to KNOW what you are doing! If you don't know what you are doing, then it doesn't matter if you are On-Line or Off-Line... you're likely to break something, or hurt someone.

I am probably missing something here but is that not how RS-Logix's does it or something real similar.

My question here is how you could do anything and not effect scan time. Everything takes time so unless you set some type of constant delay that you would handle these processes in then you would have to have a delay even if all you are doing is viewing a program.

Hhmmmm... Do not think I am explaining my thought correctly. Let me try again

Every function takes time. Increase the number of functions then total time to cycle back to start increases.

 

[geniusintraining]

...but I have seen the S5 in action and I find it to be a rugged PLC....

Rugged is not the correct word...oh wait that’s the other thread...but I would call them armor plated...I have 10ish..they are great. I have lost one input card in 13years and no outputs

...Why would TI suddenly introduce STL into the S7-200? Previous TI designs did not have STL or low level programming. The Koyo designs ( TI305, TI405) could show their rung in a STL like manner but then these are Koyo designs not TI. Evidence points to Siemens putting a lot of constraints on the former TI engineers or the S7-200 was largely developed by Siemens....

Now Peter has brought Koyo into the loop, AD is Koyo correct? Why is AD so much different the all mentioned above? I have all of the mentioned so when I say they are different... trust me (wait no TI's)

So my question is. Did Satan really invent STL?

No you are confused, that was Terry, close

 

[Peter Nachtwey]

There would have to be a separate processor for managing the content of the inactive memory area. That processor should probably also control which area is active.

And where does Stephen get this separate processor? His PLCs are already designed. Besides it isn't necessary. I think you need to think this through. You don't need two memory areas. Just a way of keepging track of just the old and new rungs and which ones are active. Old rungs don't need to be deleted from memory. If you look to the left of the rung you will see an indicator of the amount of memory used for a rung which is usually insignificant.

Everything you do on a PLC will affect the scan time unless you fix the scan time at some amount that will not be exceeded. The old Modicons could fix their scan times. I don't know about others.

We fix our scan times to be the same as the PID updates.

 

[Clay B.]

And where does Stephen get this separate processor? His PLCs are already designed. Besides it isn't necessary. I think you need to think this through. You don't need two memory areas. Just a way of keepging track of just the old and new rungs and which ones are active. Old rungs don't need to be deleted from memory. If you look to the left of the rung you will see an indicator of the amount of memory used for a rung which is usually insignificant.

Everything you do on a PLC will affect the scan time unless you fix the scan time at some amount that will not be exceeded. The old Modicons could fix their scan times. I don't know about others.

We fix our scan times to be the same as the PID updates.

Ok..probably stupid question...

Are your scans running at the same time as you PID updates? So when the scan is finished the PID update is finished also?
Is the reasoning for this to make sure whatever is processed in the scan is also processed in the PID?

 

[Peter Nachtwey]

Not a stupid question

Are your scans running at the same time as you PID updates?
So when the scan is finished the PID update is finished also?

The CPU can do only one thing at a time. During the interrupt, the PID comes first because the time between the data acquisition and the PID updating the output is critical. This is phase delay and it must be minimized. The PLC or user programs are executed immediately after the PID scan. This allows the user program to tell the axis what to do the next scan or interrupt. All this typically takes about 100 microseconds. When the interrupt is done the processor executes idle routine tasks like Ethernet communications until the hardware generates the next interrupt. They key point I was trying to make is that manyt PLCs can not fix the scan time so everything affects the scan time. There is no idle time in which to do back ground tasks like communications and updating the ladder.

[/quote]
Is the reasoning for this to make sure whatever is processed in the scan is also processed in the PID?[/QUOTE] If need be, yes. This is handy for changing gains on-the-fly before each PID update. More importantly, how can you write a program for controlling motion if you don't know when or where the next update will occur? Everything must be deterministic. We must be very careful about using CPU time. We must be able to monitor the motion controller without affect the PID scan time.

 

[Terry Woods]

Peter...

I'm simply describing a system that I think would allow total flexibility while programming on-line... and, do so without affecting scan-time.

When it comes time to process the code, the processor fetches the code... from somewhere... and executes it as defined. If both memory areas are identical, except for content, what difference does it make to the processor which memory area it works with? As far as the processor is concerned, NOTHING has changed! It will see that the code is unfolding differently, as if the processor really cared, however, in terms of doing it's job, it continues to do so without missing a beat.

Let's say that you are the processor. You are sitting at a desk with your back to a whiteboard. The whiteboard contains the instructions and the data that you need to execute the process. While executing the process, you turn to the whiteboard, fetch the next instruction and the necessary data. You then turn back to your desk to execute that instruction. When you are done, you turn back to the whiteboard... if you have data to return to the whiteboard, you do so, and then fetch the next instruction and any required data. And so it goes until you complete the last instruction including updating any data at that point.

Having finished that part of your responsibility, you then move on to perform certain housekeeping activity.

You then return to the whiteboard and execute the code again.

And so it goes... code, housekeeping, code, housekeeping...

Meanwhile, the programmer is making changes to a copy of your instructions on another whiteboard. The programmer then indicates to me, the memory area processor, that he is ready for the new code to be implimented.

The next time that you are busy with that housekeeping... I, the memory area processor, copy the current data from the current whiteboard to the other whiteboard. Then, before it is time for you to turn back to the whiteboard to execute the code... I roll the second whiteboard in front of the first one.

When you turn to the whiteboard... you simply continue as you should... being none the wiser.

The memory change should be totally transparent to you, the processor.

As far as the additional processor for managing the memory area content... well, electronic hardware is changing all the time, isn't it?

 

[S7Guy]

They key point I was trying to make is that manyt PLCs can not fix the scan time so everything affects the scan time. There is no idle time in which to do back ground tasks like communications and updating the ladder.

Just curious. You use S7 cpus, right? I know the scan time can be set for the 400 series, but I'm not sure about the rest.

On some CPUs, I have seen some really hokey methods of making sure the scan time doesn't get too long. For instance, one program I looked at calls the real time clock during the scan, and interrupts the scan if too much time has passed. It worked I guess, but there are better ways.

 

[Peter Nachtwey]

Just curious. You use S7 cpus, right?

I really don't use PLCs, my customers do. I have learned how to program them so I can write example programs. It is faster, and more efficient, for me to just write an example program once that many customers can copy and modify to suit their needs.

On some CPUs, I have seen some really hokey methods of making sure the scan time doesn't get too long. For instance, one program I looked at calls the real time clock during the scan, and interrupts the scan if too much time has passed. It worked I guess, but there are better ways.

This would be 'hokey' and very poor. Checking the timer would take a lot of time. It would be best if the timer activated an interrupt that saved the current state of the ladder and processed the overhead and then restored the ladder state so it can continue from where it was interrupted. This way even rungs at the end of the ladder would be executed.

 

[mjcandlec]

Yes,Yes,Yes

Fine tuning PID loops to real-life results, is just one of many benefits.

 

[TConnolly]

OLD THREAD ALERT.