sah676

To avoid confusion among those of us reading this many years later, this is incorrect. You can indirectly reference the bits of a DINT or INT using the notation Test.[bit] where Test is the DINT whose bits you want to look at and Bit is the array index. The original post forgot the dot; a small but crucial omission!

Even better, there's a function which does exactly what you want: SPD. |----------------------[sPD X0 K60000 D0]-------| This will count rising pulses of X0 for 60 seconds, then store the result in D0, then start again. The general form is [sPD <S> <n> <D>] where <S> is the input you want to count, <n> is the time period in milliseconds (16bit) and <D> (16 bit) is where you store it.

Yeah, rising pulse of a single bit is still in structured ladder. In my case I'm taking the rising pulse of (Trans && NOT TrBusy), with an arbitrary number of operators before the PLS.

For anyone who finds this in the future, MEP is the direct equivalent of the result rising pulse arrow. . Obviously it works identically to PLS but has one less output argument.

Quick reply! Thanks, PLS will do the job for me. Can't help thinking it's very ugly though! Welcome to function block diagram I suppose. Not as nice as a tidy little up arrow. Thanks again.

Hi all, I'm making the leap from traditional ladder to using structured ladder with function blocks. I had been using structured project with traditional ladder function blocks (sort of semi-structured) but my current job is on an FX3U, which only allows completely unstructured projects (a big lump of MAIN) or structured project with structured ladder. I've had a battle to find the equivalents of many of the old instructions, but I've got stuck at "Operation Result Rising Pulse" - you know, good old Alt-F5, rising pulse of whole chunk of logic rather than a single bit. (see pic). There is a function block R_TRIG, but I'd really rather not use a big ugly FB and have to declare every instance of it. Anyone know if this instruction is still available?

Thanks mate! It was an interesting problem. I'd never realized FLOATs would behave like that when they got large. It's something I'll be looking out for myself.

The problem is that with a FLOAT data type you only have 24 bits of precision. The other bits specify where the decimal point is (and + or -). Once you go above 16,777,216 (2^24) the smallest number you can add is 1. As the other guys have been saying, adding 0.1 doesn't change it because the precision bits are taken up with representing the whole part of the number. It's easy enough to work around: Once you reach 16,777,215 just tick some other register (D10 e.g.) up by 1 and start again at zero. The total number is just (16,777,215*D10)+Running total. Of course, this will still be rounded because the result is stored in a FLOAT with the same limitations. But at least adding up will continue no matter what the total is.