Latches question in compactlogix

I did go looking for an original SLC program and couldn't find one, but I did find a whole slew of remnant logix files. Half started attempt's renamed so many different dates, I couldn't open them all. The one file I found that was most similar to whats in use today does have some instructions in different places, specifically the couple I seem to not be able to crack why they loop. I can't get back over to that machine until next week probably but I have some clues and some new ideas. It really looks like this was someones first attempt at doing a logix upgrade, or perhaps programming in general. Literally over 20 iterations of the main file, not even .bak files....anyhow, I didnt intend for this to be a debate on the virtues of 'to latch or not to latch...'. It is what it is, someone wrote the thing, I don't have an option of a redo, so I have to chip away piece meal until I get to the other side where it actually works properly...If anything, what work I have managed to do, I had an extremely happy operator stop me and thank me for "whatever you did man, wow, its running great man". I call that a win.

There are issues with using set/reset (latch/unlatch) on outputs directly in the main code if used excessively. I normally put all outputs into a single block and use markers/bits/flags whatever you want to call them, in the program/blocks and use these to drive the outputs, this makes monitoring to find problems easier as the combination logic driving the output is in one ladder block and then if looking for what is holding the output on (or off) it can be seen and then work back through the logic. although a bit messy I very often create a block for inputs and map these to internal bits. This then allows for simulation without real I/O. Use the internal bits within the main code blocks and do not call the Input map block, write other blocks with simulation code (for example A valve with position limits not output bit time delay = closed bit and output bit time delay = output bit). this allows for simulation testing I also do this with analogs so without simulation programs testing is easy, once complete take out calls to simulation blocks and put calls in for I/O mapping.

parky said:

I very often create a block for inputs and map these to internal bits. This then allows for simulation without real I/O. Use the internal bits within the main code blocks and do not call the Input map block,

Click to expand...

When I was learning PLC's years ago I was taught this, and was told that this was actually faster than reading the input map throughout the program.

I still do this, but have tested the 'faster' theory and found it not to be true for digital inputs (at least on the SLC family, I was taught on PLC 5's so it might be different on that platform)

Unless you have some really good simulation software like PICS simulator and a PLC that allows it to mimic real inputs this is the best way, you only need the processor or the sim built into the software. It saves having to wire inputs or use rather cumbersome "buttons" in the sim program. As I said before by using timers, counters etc. you can make it just like the real world for example parts passing a photocell, filling vessels, valves opening & closing.
There are two simulation packages I have used in the past, one was called Prosis but this was dedicated to Siemens S5 and came with a card that plugged into the rack. The simulation had to be written in Pascal and worked well as it could simulate all real I/O, however we tried to use the timer interrupt in the pc and it crashed the HD as Prosis used it in their wrapper code The other was PICS simulation, this is brilliant but expensive and you had to buy I/O drivers for each type of PLC and could only simulate real I/O on AB as they SLC had ability to Disable real I/O in processor I/O map.