Best practices for variable linking in Beckhoff/Twincat 3.1

[ivo.maenen]

Here is a scenario in which I accidentally took down half a plant with.

I was given a small window of time to shut everything down and add some IO points to a fairly large system. That program had a mix of wildcards and fixed addresses. I added some additional fixed addresses that happened to be higher than the auto generated addresses for the wild cards. TwinCAT regenerated and changed all of the auto generated addresses. I linked the new IO and restarted the system. As we tried to restart the system a large portion of the IO no longer worked. After a bit of time digging through, I discovered that re-addressing also deleted the links to all of those points.

That's the reason why you should use wildcard-adressing (according to Beckhoff).

When you insert an IO-card (see my attachment Beckhoff 2') the previous adressen can (not must) shift according to the type of card you insert afterwards.

A digital IO-card does not change the range of adresses, analog IO and other special cards do change the range of adresses also the range of the digital IO-card. That was the point I wanted to make with 'Beckhoff 1' and 'Beckhoff 2'.

Archie,

I did not realise that I had an Ethernet/IP-card inserted in that file. So it was not intended as a part of the question.

The question, or rather the remark what I wanted to make was that absolute adresses do change when you insert a not-digital-card afterwards.

 

[kolyur]

ivo.maenen, in your screenshot I saw you pointed out the addresses listed in the I/O section (rather than Twincat memory addresses). I'm confused about how all the addressing relates. I swapped two digital I/O cards in my rack and when I reconfigured I got an error--as expected--that the configuration didn't match. There were some choices to manipulate the I/O, I probably picked the wrong one, but it wiped out all my links. They were easy to reestablish since I had addresses on my variables. But I noticed that the I/O addresses (55.x in my screenshot) followed the swapped modules. How are these related to the linking? Or can they be?

 

[ivo.maenen]

Kolyur,

watching your last post I realised that this is Twincat 3 and not 2. I only use Twincat 2, so maybe it's better I stay out of this discussion.

I have attached a pdf, showing you the way Beckhoff has told me how to link my global vars and also the reason why you need to link.

Since I'm relative new to Twincat, I can also learn new things.

I like what Archie did by naming the different IO-points so that you know which card and IO-point you're using (see attachment 'IO-naming'.

But I can not find a way how to use or import this name inside PLC-Control (Twincat 2).

 

[RocketTester]

I have always used wildcard declarations in PLC code (ex. %I*), probably because I never grew up w/ early PLC's and came to them as an engineer. My variable names are descriptive rather than indicative of module position. For example, an array of digital outs named DO[1] thru DO[128]. I keep side documentation of how they are linked to physical I/O, and they may go to different module types (5V, 24V, mechanical relay). The reason for a DO[] array is that it simplifies the PLC code, allowing looping thru all of them. On the Windows HMI side, I manage project-specific names (ex. DO[1].ChanName = "Motor 1 Start")

In System Manager ("System" in TC3), the fastest way to link them is under "PLC Instance", where I/O is in a list. I can sometimes get "array mode" to work where I can map say a group of 16 to a 16-chan module in one click. If not, it is fairly quick to link one-by-one since if you select "same type" and "unused", the next one in the list is the default so you can link quickly by click-enter (using 2 hands) or such. But, be especially careful with binary variables because the list has many status variables you might not want to link to.

My systems are not continuous running and no worries with down-time. If I add say a DO module, I usually renumber the following DO's to keep them sequential with the modules. But, that is not mandatory since I recall the links stay with the original module when you insert a new module (post 16). Actually, it is the "module position" in the "process image" that matters, i.e. you can substitute another SN module of same PN (or compatible) and it will work the same.

System Manager has a "Process Map" graphic (or such) that diagrams how I/O is mapped, but I have never been able to make much sense of it. I guess it would mainly help in showing if you have a "crossed stream", i.e. something out of sequence

 

[kolyur]

This has been a very helpful thread, thanks to everyone.

The reason for a DO[] array is that it simplifies the PLC code, allowing looping thru all of them.

This is the reason I was originally thinking of using arrays, so that I could quickly zero my outputs or do other manipulation without having to work on the bit level. I discovered that by assigning fixed addressed I can still do this to some extent. For example if my outputs are %QX1.0, %QX1.1, etc., I can address the entire byte as %QB1 in the program and clear it or whatever.

In System Manager ("System" in TC3), the fastest way to link them is under "PLC Instance", where I/O is in a list.

Good tip, I knew there had to be something like this where I could see all my links in one place but I hadn't found it yet. Thanks.

 

[EasyPanicButton]

I know this is a bit late, but Christmas cheer and laziness and spare time

Can you dictate to System, what address it should use for each module/slice in the rack?

We don't deal with a lot of I/O so it's not a huge chore to link our I/O, like maybe a couple hours if that, but I wanted to know for the future how to link say the I/O for a weld line, where there maybe couple hundreds points of I/O.