GX WORKS2 Rising/falling edge detection in ST.

[parky]

This works when I compiled there were a number of errors
1. the variables Real_xx would not compile because real is a reserved word (no idea if you have them as local or global variables but I suggest you need them as globals
The IF / Else etc produced another compiler error as it was incorrect.
Why are you setting the output to full scale on first scan ? what is the point, if you have something connected to it i.e an analogue sensor it will overwrite it.
If not it will never get to overscale ?

 

[mikeromeo]

I have never worked with FX3U Plc's, but, in the original post it seems that these lines are commented out. That may be why the code is not working as expected.

I commented them out because they were not working as expected, and replaced them with the PLS/PLF instructions (which also didn't work)

I chose REALs so there would be no problem with overflow: the counters will stop incrementing at around 16M (2²⁴), which is fine because they are only a diagnostic, but that not cause a CPU fault, which happens when incrementing integers on some PLCs.

Good to know about overflow potentially causing a fault, thanks.

 

[mikeromeo]

This works when I compiled there were a number of errors
1. the variables Real_xx would not compile because real is a reserved word (no idea if you have them as local or global variables but I suggest you need them as globals
The IF / Else etc produced another compiler error as it was incorrect.
Why are you setting the output to full scale on first scan ? what is the point, if you have something connected to it i.e an analogue sensor it will overwrite it.
If not it will never get to overscale ?

I'm setting one of the analog outputs to full scale just to use it as a 10v reference voltage source in this test. FWIW I wouldn't do this in a real application, it is just to allow me to use a potentiometer to be used to simulate a sensor.

I set the variables as globals with those names (lower case) and it compiles without any warnings. Very interesting that it works for you, what version number GX Works 2 are you running? I only went for this FX3 clone as I got a loaner laptop from work with GX Works2 already on it.

 

[parky]

It does not matter, yes there may be difference in variable names from version to version but definitely on mine Real, or any name the same as an instruction (first word) will not compile, however, if it is a following word (text) then it allows it, I know there are version differences as some programs written in the early GXIEC version you could use the same name for input variables on function blocks as the variable actually passed to it, in GXWorks it is an option you can set especially when converting the GXIEC file to GXWorks. Mine is 1.620,
The reason yours did not work or seems to be is definitely not the version on GXW, when I tried to compile the IF Else Then etc. were wrong, all I did was remove the else, added a not M8002 in the call to the read analogue, (note I should have added that to the next IF but forgot, I have no idea why you need to worry about disabling the other logic i.e. reading the analogs or outputting them on first scan as it will not make any difference the scan is too fast to see any problem in reality but probably a good idea if you are setting or controlling outputs.
Here is a better version, there was code in yours that was not required, why create a rising & falling edge when the LDP & LDF functions are there to use.
No need for else as you need to evaluate the falling edge just extra code you are using & not required, (don't worry we all do it then when we look at it again we often think why do I need that).

 

[drbitboy]

I'll say it again: the problem is not with the code; the problem is that the entire routine of statements is not being called, and so the statements are never evaluated. This is obvious from the posted video.

As far as REAL_... variable names, change them to REEL_... instead.

 

[parky]

Just change the code as above, this works as you can see from the status it is incrementing the reals.
it's smaller, I have already shown that just by putting a char infront of the real allows compilation there may be a setting in GXW2 that allows reserved words but I have never seen it, only the ability to use the same symbolic name in local & inout variables in FB's.
Also from the OP's posts, it seems he is using globals, but if these globals have been assigned to actual D registers (they don't have to be) then he must remember the registers are 16 bit so a real takes up two registers i.e.
D100 +D101, as assigning D100 to Real_rise & D101 to Real_Fall one will overwrite the second register & probably display NAN (not a number).
I wouldn't bother with the IF/END_IF no need for jumps just create the oneshots & use the in-built functions to enable the calls to those functions.
For example: rather than use IF xxxxx then
Create the required oneshot i.e. M0 := LDP[TRUE,M8013] AND NOT M8002;
Just put each function like WR3A[ M0,0,0,D0];
Simple & smaller code. & no JC's in the compiled code

 

[parky]

I have just put my program in a clone & it works without problems (although I did use different DW, I borrowed a clone off my mate, Just as a matter of interest for others that may be playing with clones the one he has is a transistor output not relay, I was sceptical if certain functions may not work as in a genuine FX, however, while I had the clone I tried the PLSY function (note this only works on transistor type outputs) & the functions I have tested work fine, one thing to bear in mind is that the version I have here the transistor output is not quite what you think the common is exactly that or put it another way it is 0v, so it is NPN output i.e. sink not source.

 

[mikeromeo]

Just change the code as above, this works as you can see from the status it is incrementing the reals.

Unfortunately this doesn't work on my FX3 clone, I see exactly the same issue as my original program; i.e. those IF blocks are never executed and the debug variables never get incremented. If the clone is running some very broken firmware this could be explained, but I still don't understand how the ladder program works as expected if this is the case.

If you have a few minutes spare could you post the compile output (i.e. instruction list) that you code generates for the program you posted above? I've attached mine.

 

[drbitboy]

i.e. those IF blocks are never executed and the debug variables never get incremented.

How do FX/Mitsi break up tasks and routines and such?

Could this code be placed in the "main" continuous task; surely that code gets executed?

Are you sure the PLC is actually in RUN mode?

 

[mikeromeo]

I'm very sure it's in run mode, the RUN LED is illuminated, and the ladder works when the switch is in this position. I have tried manually toggling the switch before and after programming and also allowing GX Works to automatically disable/enable run when programming and the result is the same. Also the first IF block does gets run since I see the analog output get set to 10v.

Interesting you ask about the way that the code is broken up; in the ST compile output I see the conditional jumps that I would expect from IF blocks. However if I open the ladder project the option to "View compile output" is not present, but it allows the instructions to be exported as a CSV file (attached) but there are no jumps at all, not sure how that could ever work. Perhaps this export doesn't give the full set of instructions?

 

[drbitboy]

could you put the W_all := W_all + 1.0; statement at the top of the routine and outside of any , and add a few more?

• W_2 := W_2 + 1.0; before the IF LDP ...
• W_3 := W_3 + 1.0; before the IF LDF ...
• W_4 := W_4 + 1.0; after the last END_IF;

If, as you say, the first IF-END_IF is executing, at least once, then that might verify what, if anything, is happening to the other statements. I am usually loath to suspect compiler or hardware/firmware bugs, especially with such simple code, but who knows.

 

[parky]

Yes in ladder it will not use jumps to subroutines, the reason St uses jumps is because the IF statements as I say you can program in ST without the IF statements the reason is that unlike many IDE's mitsubishi made the compiler in GXW2 to be compatible with ladder/IL, so it will use conditional/unconditional calls to subs as well as using intermediate "Reserved" bits/words in the compilation these are usually in the region of M9000 not normally used, also have you ensured that your floats are double words i.e. if you have called them globals & assigned D memory to them that you make sure you do not overlap them for example
If you use consecutive D registers this will not work
My_Float, Single precision, D20
My float1. single precision, D21
As they need two 16 bit words it takes 2 words per tag
My_Float, Single precision, D20 (D20 + D21)
My float1. single precision, D22 (D22 + D23)

 

[parky]

Right.... I have borrowed my mates clone & it does appear that although the original code works on a true FX it does not work properly on a clone, below is something that does work as I have fully tested it on his clone, however, there are some issues you must be aware of The IF statements for some reason do not work correctly as it must be something to do with how the clone supports the conditional jumps, Here is the alternative so it does not use the IF statements.
The analogue output is also a little iffy, it will not give out 10v (although I currently have it running on 22v only psu I have) it seems to output a max of 9.68v also if you go over the HFFF then it drops to zero so you cannot test for over HFFF (4095 Dec) or 10v in other words overrange defaults it to 0. (Note: for testing the Y0 output I used a lower value in the compare).So what I have done is embedded the logic i.e. the rising & falling edge triggers in the calls to the functions.
In reality, when you write your normal program there is no reason why you need rise/fall, just do it either continuously read or write on one or the other, I know Mitsubishi show one scan triggers on read/write of the RD3A WD3A but other than speed of processing it is not strictly required. certainly not required for doing the compare of the values i.e. in other logic. I suggest on the clones you do not use ST with IF statements (CJ).
Attached is the running screen grab & the actual file

 

[goghie]

Just for info, when you go online with clone, and go to the PLC Diagnostics, what is info about CPU version?

I had a few month ago close encounter with fake Mitsubishi FX2N, customer bought without knowing it. At first site everything looked OK - the customer bought PLC it from E-bay, although I was a bit confused, how he managed to buy new one. Later I saw that CPU version was V2 (or V2.1), so it did not support many standard instructions.

 

[mikeromeo]

Right.... I have borrowed my mates clone & it does appear that although the original code works on a true FX it does not work properly on a clone, below is something that does work as I have fully tested it on his clone, however, there are some issues you must be aware of The IF statements for some reason do not work correctly as it must be something to do with how the clone supports the conditional jumps, Here is the alternative so it does not use the IF statements.
The analogue output is also a little iffy, it will not give out 10v (although I currently have it running on 22v only psu I have) it seems to output a max of 9.68v also if you go over the HFFF then it drops to zero so you cannot test for over HFFF (4095 Dec) or 10v in other words overrange defaults it to 0. (Note: for testing the Y0 output I used a lower value in the compare).So what I have done is embedded the logic i.e. the rising & falling edge triggers in the calls to the functions.
In reality, when you write your normal program there is no reason why you need rise/fall, just do it either continuously read or write on one or the other, I know Mitsubishi show one scan triggers on read/write of the RD3A WD3A but other than speed of processing it is not strictly required. certainly not required for doing the compare of the values i.e. in other logic. I suggest on the clones you do not use ST with IF statements (CJ).
Attached is the running screen grab & the actual file

Thank you for all your help, I really appreciate it. I suspected this was a clone problem, but at least I have learned a bit about the lower level operation of these things. I'll give OpenPLC a try as I have nothing (but my time) to lose on this pile of parts now. FWIW the analog outputs on mine have a full scale of around 10.26v, clearly not a very well controlled parameter on these clone devices (to no-one's surprise).

Just for info, when you go online with clone, and go to the PLC Diagnostics, what is info about CPU version?

I had a few month ago close encounter with fake Mitsubishi FX2N, customer bought without knowing it. At first site everything looked OK - the customer bought PLC it from E-bay, although I was a bit confused, how he managed to buy new one. Later I saw that CPU version was V2 (or V2.1), so it did not support many standard instructions.

I get a CPU Version of 0.0 which clearly isn't correct. It doesn't report any errors during program execution either, presumably it's silently ignoring unsupported instructions.