Productivity/Codesys: I started a revolt on AD's Forum

kallileo said:

This is why an easy software update method is necessary in order to fix a bug or add a new feature.

Click to expand...

I think you are referring to that if the PLC is actually a Windows or Linux device, then an update can installed by simply copying a file onto the device.

At least for Siemens S7-1200/1500 there is a free "Automation Tool" with which an end-user can load a program update onto the CPU without having the full programming software.
Another way which many PLCs support is to send the content of a PLC flashcard by email, and the end-user can simply copy the files onto the flash-card in a standard card reader.

kalabdel said:

...

I believe it was drbitboy (I think that's the name) who expressed his dis-satisfaction with how Siemens timers work and that he expected them to update in a traditional way (my words) sort of buffered, while I wanted timer data as real time as possible and it's up to me to use it "cautiously".

Click to expand...

Yes, but I realized later that that was my bias from how my first experience with ladder went; basically a timer is an input, and the inputs are all buffered between each program scan.



That's a fair point about using it cautiously once you know how it works.

kalabdel said:

I don't get why No interrupts for processing, not sure what he meant by that.

Click to expand...

Funny: to me this seems obvious that it is related to the timers and buffered inputs mentioned above: it means the coder can assume a static system for the duration of the program scan. As long as the PLC pragram scan frequency is fast compared to the process, the digital PLC model* will behave similarly to analog controls, which controls the PLC was meant to replace.


* Any computer program is a model of a subset of reality; about the only real design decision is each model's level of fidelity, because everything else flows from that. For example, say there is a conveyor with products, a vision system to detect defects, a reject gate to divert defective products, which gate is much further down the conveyor so several products can be between defect detection and rejection. Queries about this type of system come up regularly here. If I know the "speed" and "distance," i.e. timing, of the conveyor, because either "time" is measured by a prox on the conveyor's drive gear or conveyor speed and the PLC's internal clock are constant "enough," then I might use a bit shift instruction to track parts from defect detection to rejection; if the timing has some noise, I might use several ("seconds" worth of) bits to represent each product i.e. put a deadband around each defect detection's arrival at the reject station. If known timing is not the case i.e. cannot be modeled accurately enough, e.g. because there is a ramped section where boxes shift in an unpredictable manner, but the order of the products stays constant, then I might use two prox'es, one at either station, to trigger FIFOs i.e. a different model. If the system had to start up with boxes already in place, then I might find some way to reject all boxes for a fixed time before releasing the first box from the detection station. Further, if the process is too complex to model 100%, there may be an acceptable non-rejected defect rate that can be modeled well enough.

kalabdel said:

How do you handle that issue with CodeSys compatible PLCs?

Click to expand...

Schneider EcoStructure M241/251 (Codesys based) PLC's can update their software and firmware/image using a standard SD Card.

We also use some Exor HMIs with Codesys Soft PLC to control a custom Modbus TCP I/O board. It's even easier there as the HMI runtime runs on Linux and both Codesys and HMI runtimes can be updated using a USB flash drive. There is script on the USB that automatically copies the Codesys "Application.app" file as JesperMP mentioned above.


It also seems that the Simatic Automation Tool isn't a free product.

JesperMP said:

CFC is coming with TIA V17, slated to be released Q2 2021.
But honestly, CFC with an S7-1200 or an AD PLC !?

Click to expand...

I'm sorry, my statement was half OT. I would probaby not use an AD PLC unless a client demanded it, which seems highly unlikely. I merely pointed out a feature gap between TIA and codesys. Great news though that they will implement it next year, i've been missing that feature alot. To bad it's not mandated by the IEC 61131-3.

kallileo said:

I think Codesys wasn't designed for typical PLC programmers that use Ladder logic, it reminds me more of some kind of IDE oriented for embedded software engineers who develop applications for microcontrollers and prefer text language coding rather than graphical presentation like Ladder.

Click to expand...

The different languages each have a domain where they are useful, and certainly the PLC does not care because however it is written it gets compiled to equivalent machine code.


The ladder/procedural(e.g. Codesys) difference doesn't matter to me; I have orders of magnitude more experience in the latter (python, c/c++, fortran, perl, java, javascript, bash, etc.), but even so I would still prefer ladder for "contact and coil" logic, first of all because I don't have to hold/visualize/translate-to a model in my head as I would with Codesys, while with ladder syntax said model is right in front of me, and second because at least with ladder the maintenance electricians, while not programmers per se, could be taught to look at (clean) ladder code and figure stuff out as they already understand the syntax*.



As @kalileo points out, once you get into inter-PLC communication and other applications beyond contact and coil, then it will likely be no longer feasible for the electrician to be able to troubleshoot with ladder, so Codesys makes sense there.


* assuming HMI displays could not display the information equivalent to ladder for troubleshooting; if I could design decent diagnostic HMI screens for maintenance to use in troubleshooting, then the language choice becomes more or less irrelevant.

drbitboy said:

The ladder/procedural(e.g. Codesys) difference doesn't matter to me; I have orders of magnitude more experience in the latter (python, c/c++, fortran, perl, java, javascript, bash, etc.), but even so I would still prefer ladder for "contact and coil" logic, first of all because I don't have to hold/visualize/translate-to a model in my head as I would with Codesys, while with ladder syntax said model is right in front of me, and second because at least with ladder the maintenance electricians, while not programmers per se, could be taught to look at (clean) ladder code and figure stuff out as they already understand the syntax*.

Click to expand...

I find it really interesting how a lot of people get into huge discussions about using a certain language over others when all have applications or they'd just be dropped eventually. In my case it was between Siemens FBD and STL and these two groups of people would go crazy defending both as the best in absolute terms rather than accept that STL is an absolute nightmare for contact and coil unless you're very, very used to it. But FBD (and to a certain extent Ladder) are atrocious when you need to, for example, carry out complex instructions without a Compute or similar instruction and STL there shines by making use of the accumulator where the result of operations "carries" forward.

cardosocea said:

I find it really interesting how a lot of people get into huge discussions about using a certain language over others when all have applications or they'd just be dropped eventually. In my case it was between Siemens FBD and STL and these two groups of people would go crazy defending both as the best in absolute terms rather than accept that STL is an absolute nightmare for contact and coil unless you're very, very used to it. But FBD (and to a certain extent Ladder) are atrocious when you need to, for example, carry out complex instructions without a Compute or similar instruction and STL there shines by making use of the accumulator where the result of operations "carries" forward.

Click to expand...

Agreed, as you can tell from my post. The available libraries (instructions, in the PLC context) are far more important than the language.



An the "atrocious" comment is very accurate: I needed natural logarithm for ladder ina MicroLogix 1100: I think it was several rungs and around twenty instructions to do it.

Originally posted by drbitboy:

...first of all because I don't have to hold/visualize/translate-to a model in my head as I would with Codesys, while with ladder syntax said model is right in front of me...

Click to expand...

Originally posted by cardosocea:

...accept that STL is an absolute nightmare for contact and coil unless you're very, very used to it.

Click to expand...

This seems to be a universal in languages of all type, which are all symbolic abstractions of one sort or another. I once asked an Irishman who was a fluent German speaker if he translated spoken German into English on the fly. He said that he knew he had German down when he DIDN'T have to do that anymore. Spoken German just put the picture right in his mind.

As we all know, the older you get the harder it is to learn a new language. This applies to programming languages as well, thus the pushback from the Ladder-speakers of old. I happen to be one of those myself but I don't mind learning new languages, at least programming languages. My German from 30+ years ago is almost non-existent now.

Keith

kamenges said:

My German from 30+ years ago is almost non-existent now.

Click to expand...

Guten Tag, Louisa!


(you may be too young to get that; it is from 40+ years ago)

kamenges said:

This seems to be a universal in languages of all type, which are all symbolic abstractions of one sort or another. I once asked an Irishman who was a fluent German speaker if he translated spoken German into English on the fly. He said that he knew he had German down when he DIDN'T have to do that anymore. Spoken German just put the picture right in his mind.

Click to expand...

That's a really good point, and why I am programming language agnostic (I hate them all ): when I learn a new programming language it is via understanding what it does to the bits. There are only so many things that can be done with bits (booleans, unsigned and signed integers, floats, strings, streams, etc.). To my mind tags (variables) are only ever pointers, never the quantity referenced by the tag name. The rest is bookkeeping. So while the grammar and syntax will be new, the vocabulary is old, limited, and already known.

Originally posted by drbitboy:

To my mind tags (variables) are only ever pointers, never the quantity referenced by the tag name.

Click to expand...

For some reason this is the one that has always driven me right nuts when it comes to the tags vs address argument. Do you really think that N7:0 or DB100.DBW1 is a fixed plc address? It is just another way of saying iSheetCount.

Keith

kamenges said:

For some reason this is the one that has always driven me right nuts when it comes to the tags vs address argument. Do you really think that N7:0 or DB100.DBW1 is a fixed plc address? It is just another way of saying iSheetCount.

Keith

Click to expand...

I don't care if it's fixed, but N7:0* is both an address and a way** to interpret the bits at that address. Functionally during programming I may be able to treat iSheetCount as the quantity it represents, but in troubleshooting*** that ceases to be a useful metaphor.



* or DB100.DBW1 or iSheetCoun
** float, int, bit, string, UDT, etc.
*** when the program does what I told it to instead of what I want


This was brought home to me when I forgot to dimension a 3-D, 32-bit real argument "EQUIP3" to a subroutine. When I used EQUIP3(I,J,K) on the right hand side of a formula, the compiler said "ah, that's a function" and the program went to the address of EQUIP3 and merrily executed that REAL array's bits as machine instructions. I was just lucky the CPU crashed on a bad instruction, instead of doing something and finding a return statement.