a.yearsley

We're just looking at setting up a redundant ControlLogix chassis pair. The pair communicate to a single I/O rack via Ethernet/IP, and we will also have a SCADA system talking to the redundant chassis. All the examples I've seen for redundant pair show 2x EN2T cards in the controller chassis. One card for the connection to the I/O rack. A separate card for connection to the SCADA/HMI. Is this really necessary? or just 'best practice'? I would've thought you could have just one EN2T card in each controller chassis. Then connect everything (SCADA, I/O rack, controller chassis) to a managed switch sitting in the middle. SCADA and I/O comms can be separated via VLAN. Would this work, or have I missed something?

Just resolved the issue this morning. Issue was that I had 1x instance of an AOI called multiple times throughout the program (effectively using it as a 'Function' rather than a 'Function block'). At some point in time the AOI was getting called in the slower task then, whilst processing that AOI it is being interrupted by the faster task (higher priority) ... which then tries to call that same instance of the AOI. This overlap causes the major fault (not surprisingly). Solution - declare a unique instance of the AOI for each task. Use an instance of an AOI exclusively within 1 task only. Thanks to all who replied for your insights.

It seems that 'Stack Overflow' is also linked to CPU load. If I significantly reduce the load on the PLC (decrease the update rates of the tasks) then these faults disappear. I haven't quite figured out the tipping point for my application. I think it might be ~50-60% CPU loading when I start to get stack overflow faults occurring. I probably wasn't clear but ... "JSR > AOI" is me trying to list the entire path to the rung that was faulted. Within that sub-routine there are many lines of code and many AOI's used etc. etc (i.e. the 'main' routine of the program just calls a set of sub-routines where all the actual code resides. Just a way to logically organise the code). Hope that makes sense.

Sorry - I'm unable to post the ACD file. Priorities. Fast task = 9, Slow task (one where the fault is occurring) = 10 Initially I had them at the same priority (10). I then gave the fast task higher priority (9) and continued to get these stack overflow faults occurring. If I swap the priorities (i.e. slow task is higher priority) then the frequency of stack overflows significantly reduces ... but I get task overruns on the fast task (not particularly surprised about that).

By de-activating the rung it kept faulting on ... the same fault just occurs but in an entirely different program, calling a different AOI. There are definitely no circular references within these AOIs, and each of the AOIs are pretty simple without any loops or anything like that. I've mucked around with the task parameters and noted that the frequency of the fault occurring increases based on the update rates for the tasks (i.e. if call the tasks at faster rate then faults more often). I've also noted that if I inhibit the 'fast' task then I don't get the stack overflow fault occurring at all. It'd be great to have a stack/call trace or something similar so I can see for sure if it is the interplay between the two tasks that is affecting this fault.

I keep getting a major fault occur on a CompactLogix L43 CPU which I can't get to the bottom of. Fault details: Major fault Type 04 - Program fault Code 84 - Stack overflow. Stack too small to perform operation Always occurs on the same rung where I am calling an AOI used many times in the program. The manual says to check for too much nesting of sub-routines etc. Total call stack for the rung in question is Task > Program > JSR > AOI. There are plenty of other places with more nesting involved. The CPU doesn't seem to be too heavily loaded. I'm running 2 periodic tasks (10ms update with ~2-3ms execution time and 30ms update with ~12ms execution time). On the comms side I have 1x Ethernet/IP PointIO rack (20ms RPI) and 1x SCADA (1000ms update rate with ~1000tags). Is there any way I can get a full call stack for the CPU? Any ideas as to how I can resolve the fault?

Turns out there is a standard library provided in CoDeSys for this called 'sysLibProjectInfo.lib' with an example project - ftp://ftp2.3s-software.com/pub/Examples/Projects/CoDeSysV2.3/SysLibs/SysLibProjectInfo/ Not sure why this library is not present after installing Moeller's flavour of CoDeSys. I haven't yet played with the example project but I imagine it can't be too difficult to use.

Does anyone know how to get the Project information programatically? e.g. Project's filename, directory, title, author etc. (all in 'Project' > 'Project Info ...' dialog box). It must be able to be done as this information can be accessed via PLC browser 'pinf' & 'getprgprop' commands. We want to be able to use the filename for version control rather than relying on programmer to manually update a variable with version information. NB using a Moeller PLC, programmed with CoDeSys 2.x

Thanks for the info paulengr. Time for some further research. I may end up purchasing a modbus to devicenet gateway device instead, as there's only the 1x modbus slave we need to talk to. This should simplify matter in the PLC with only 1 comms network to deal with.

Good to know it's theoretically possible. Browsing through the sample code it looks like a bit of work handling all the data ... but obviously possible. One question - how would we access the serial data from the PointIO rather than from the on-board serial port?

I have a CompactLogix (L43) PLC with Point IO remote rack (comms via DeviceNet). I want to talk Modbus (either RTU or ASCII) to a device near the remote rack. Has anyone ever tried communicating via Modbus (either RTU or ASCII) via a Point I/O serial comms card (1734-485ASC)? Is this even possible?