ALW_ON ALW_ON
---] [---+-------(OUT)
|
ALW_ON |
---]/[---+
CALL SFC 20
SRCBLK :=#OB1_DATE_TIME
RET_VAL:=#Return
DSTBLK :=P#DB10.DBX0.0 BYTE 8
Well, Ken, you better believe it. After all, we're talking Siemens.I don't believe that the ladder network JvdCande drew actually needs the OR'd M0.0 - it should work with all the MOVEs simply connected to the left rail.
Well, I do know that a lot of the maintenance guys out there do not like STL. They do like ladder a lot better. So, I always advice to use ladder as often as possible. After all, you only have to write the program once, but the maintenance people have to look at it for another 20 odd years. Have some mercy on them and don't make their lives harder than necessary.Sreev, I would stay with STL if I were you. You will get faster scan times, it is much faster to program with it, and the instruction set is more powerful. Every person that I have convinced to give STL a try would never go back to ladder again.
S7Guy said:Rdrast, I'm just curious. When would you need the DINT to INT instruction?
S7Guy said:JV, it depends on the maintenance people. I can usually take a guy aside and explain STL troubleshooting, and he picks up on it very quickly. Honestly, I can say that my STL coding has never been an issue. If my code is something that they have to look at all the time, then maybe the problem is me, not them, in the first place. In fact, during the past five years, most of my customers haven't even asked for the PLC source code anyway, since I provide an HMI that details every conceivable fault that can happen.
I'd say, 90% of the time I use S7's here, it's in conjunction with Siemens MasterDrives on Profibus. In our programs, we scale all reference and feedback values to engineering units, as reals. No problem coming IN to the PLC, (IDT, DTR), but going back to the drives, the values need to be INTS.
L 4.500057e+005
L 2.500000e+001
/R
RND
T MW 10