Schneider Control Expert - READ_VAR FBD issue

[AlexDarsigny]

Hi,

I'm using Control Expert (a.k.a Unity Pro) to program M340 PLC. I am looking for a patch to fix what I think is a bug in PLC library.

Please look at this short video : https://www.youtube.com/watch?v=t2N1-RHJUWc

Basically, I have a working communication with a Modbus slave but if I close it, my M340 is not able to recover communication. In fact, READ_VAR block seems to be stuck in an infinite loop since EN output is never TRUE even if EN input is set to TRUE multiple times. Please note I'm using a PLC simulator, I'll confirm the behavious with a real PLC soon.

Re-starting PLC fix the problem obviously but that's not a solution.
The only solution I have is to use a second READ_VAR instance with different variable for GEST or it doesn't work. I could program 10 instances waiting for the previous one to fail but that's really not a good solution. I tried to play with everything attached to READ_VAR (especially GEST array) but couldn't find a viable solution.

Any ideas? Thanks!

 

[dalporto]

READ_VAR c'était bon pour les Quantum, arrives en 2023!


Pas certain de bien comprendre ton problème mais aurais-tu 2 blocs avec le même ID? Ça peut avoir arrivé si t'as importé des sections ou des bouts de code.


Fais un copy/paste sur ton read_var pis efface l'original.


-Devine je suis qui

 

[drbitboy]

what happens if you change the I_DEVICE_ADDR value to something else for a few seconds, then back to the original value (127.0.0.1?) again?

 

[chud]

Need to see what your gest_management variables are set to. Als what version of control expert are you using?

 

[AlexDarsigny]

Good news. It's a PLC simulator problem. With a real PLC, READ_VAR is never stuck and recovers communication everytime.

I wonder if the automatic IP assigned to PLC simulator (127.0.0.1) might have something to do with the issue...

PLC simulator : 127.0.0.1
Modbus slave for test : 192.168.112.60

I can assure you that I tried to change all inputs and there is absolutely nothing that unfreezes READ_VAR block (in PLC simulator mode!) except a PLC restart. I'm using Control Expert V5.2.

 

[dalporto]

Ohh, the new V5.2!

 

[AlexDarsigny]

Good news. It's a PLC simulator problem. With I'm using Control Expert V15.2.

Fixed.

 

[Lare]

Good news. It's a PLC simulator problem. With a real PLC, READ_VAR is never stuck and recovers communication everytime.

I wonder if the automatic IP assigned to PLC simulator (127.0.0.1) might have something to do with the issue...

PLC simulator : 127.0.0.1
Modbus slave for test : 192.168.112.60

I can assure you that I tried to change all inputs and there is absolutely nothing that unfreezes READ_VAR block (in PLC simulator mode!) except a PLC restart. I'm using Control Expert V5.2.

Actually there was at least bug on read_var and write_var blocks on M340 before. Gest paramters activity bit can get jammed to locigal true state and after that communication is stopped. Not sure if Schneider have fixed it to firmwares and if they are when?
Fix was before to reset activity bit on PLC code if it gets jammed. (or rebooting whole PLC)


There is two different timeout parameters, hardware timeout and software timeout. They have to be on correct order or modbus querys are sended before you have timeout on query before which don't get reply for slave.
This leads to collisions on serial side and lot of querys are timeouted for CRC or other errors.



Both timeouts also needs to be setted so that infinite timeout isn't used and activity bit is resetted automatically on errors. (which PLC didn't do allways before)


Gest parameters should also be same for every read_var and write_var if you use serial comms and same RS port. You should also sequence serial modbus querys on PLC code. (if activity bit is false then next query with little time cap between different querys.)


On TCP side you can use different gest parameters and querys are sended same time outside from PLC., but there also limit for simultaneously read_var and write_var blocks / Ethernet port.




How you get PLC simulator to work read_var and var_blocks?
Before it was blocked on simulator side si that you allways needed real PLC for testing.

 

[AlexDarsigny]

Actually there was at least bug on read_var and write_var blocks on M340 before. Gest paramters activity bit can get jammed to locigal true state and after that communication is stopped. Not sure if Schneider have fixed it to firmwares and if they are when?
Fix was before to reset activity bit on PLC code if it gets jammed. (or rebooting whole PLC)

A.D. : From what I observed with real PLC, the activity bit gets stuck to 1 when communication is lost but it starts to toggle when the communication is back. The bug you're referring to might be fixed.


There is two different timeout parameters, hardware timeout and software timeout. They have to be on correct order or modbus querys are sended before you have timeout on query before which don't get reply for slave.
This leads to collisions on serial side and lot of querys are timeouted for CRC or other errors.

A.D. : I'm only doing TCP/IP Modbus communication, does this still apply?
Is timeout delay set in GEST[3] the software timeout or hardware timeout?



Both timeouts also needs to be setted so that infinite timeout isn't used and activity bit is resetted automatically on errors. (which PLC didn't do allways before)


Gest parameters should also be same for every read_var and write_var if you use serial comms and same RS port. You should also sequence serial modbus querys on PLC code. (if activity bit is false then next query with little time cap between different querys.)

A.D. : I actually do that, GEST[1].0 (activity bit) must be 0 in order to send a pulse to EN pin of READ_VAR. I omitted it in my example for simplifying the issue.


On TCP side you can use different gest parameters and querys are sended same time outside from PLC., but there also limit for simultaneously read_var and write_var blocks / Ethernet port.




How you get PLC simulator to work read_var and var_blocks?
Before it was blocked on simulator side si that you allways needed real PLC for testing.

A.D. : I think it's a new feature that came with first release of Control Expert. Using 127.0.0.1 as simulator IP, it is able to communicate with Modbus slaves and I think any other IP do not work.

See my comments in blue.

 

[Lare]

See my comments in blue.

Activity bit "force" reset don't make anyharm on PLC side. Have programmed some 10-30s delay which reset bit if it gets stuck. PL7 had these problems and M340 also had tech note of activity bit problem years ago. (maybe some over 5 years ago)


Gest parameter 3 is software timeout. (if gest is 1..4 lenght array). (usually have used 5 for TCP (500ms which is more then enought for TCP)

PLC read and write com blocks are tied to mast task cycle.
Blocks needs usually at least one scan for processing.
If you have let say 30ms scan cycle, then you cand send new reguest with cap at least 30ms (one cycle) between different send query commands.
(So fastest com is some 90-100ms for two modbus querys with 30ms scan cycle, maybe.)


Sidenote. Read_var and write_ar blocks have to enabled with trigger signal, if you execute blocks without trigger block, then block will send several querys to slaves as long as com blocks en input is on true state.
Schneider examples usually have trigger pulse anded with Not (activity bit)
Only notted activity bit before com block is not enought. It will send several querys as activity bit goes false -> true -> false -> true -> false.




TCP ports don't have adjustable hardware timeout as serial cards have. Only software timeout is (gest[3]) is adjustable and needs to be different than 0 (infinite timeout)




I think You can send some 8 or 16 modbus querys from Ethernet port simultanenously. It is sayed somewhere on help files. On P57 PLC's it depended on PLC type.
M340 probably have different amounts depending if you use inbuild ethernet port or seperate NOE card. (Seperate NOE card has also IO scanner for TCP on M340 CPU)


PLC uses different TCP sockets for sending and answering, so using read_var and write var blocks don't affect to HMI or scada communications.

 

[AlexDarsigny]

Activity bit "force" reset don't make anyharm on PLC side. Have programmed some 10-30s delay which reset bit if it gets stuck. PL7 had these problems and M340 also had tech note of activity bit problem years ago. (maybe some over 5 years ago)


Gest parameter 3 is software timeout. (if gest is 1..4 lenght array). (usually have used 5 for TCP (500ms which is more then enought for TCP)

PLC read and write com blocks are tied to mast task cycle.
Blocks needs usually at least one scan for processing.
If you have let say 30ms scan cycle, then you cand send new reguest with cap at least 30ms (one cycle) between different send query commands.
(So fastest com is some 90-100ms for two modbus querys with 30ms scan cycle, maybe.)


Sidenote. Read_var and write_ar blocks have to enabled with trigger signal, if you execute blocks without trigger block, then block will send several querys to slaves as long as com blocks en input is on true state.
Schneider examples usually have trigger pulse anded with Not (activity bit)
Only notted activity bit before com block is not enought. It will send several querys as activity bit goes false -> true -> false -> true -> false.




TCP ports don't have adjustable hardware timeout as serial cards have. Only software timeout is (gest[3]) is adjustable and needs to be different than 0 (infinite timeout)




I think You can send some 8 or 16 modbus querys from Ethernet port simultanenously. It is sayed somewhere on help files. On P57 PLC's it depended on PLC type.
M340 probably have different amounts depending if you use inbuild ethernet port or seperate NOE card. (Seperate NOE card has also IO scanner for TCP on M340 CPU)


PLC uses different TCP sockets for sending and answering, so using read_var and write var blocks don't affect to HMI or scada communications.

I already use READ_VAR and WRITE_VAR exactly as you specified except the thing about the activity bit that gets stuck. I'll add it in my programmation.

Thank you very much for the tips!