Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
Hello everyone,
I'm experimenting with the ModbusFB library examples and I've found a strange issue that I think is just my lack of understanding.
I'm able to connect to a slave with my code, but after a successful poll, the xDone is set to TRUE which is correct. BUT, once that happens, ModbusFB will not attempt to talk to the slave again. I have to disconnect and reconnect to get it to talk again. I cannot reset xDone to FALSE.
After I get back xDone = TRUE I set xExecute to FALSE and thought that would reset xDone, but it didn't. The only way I could get new values was to set xConnect := FALSE and initDone := false so that the system would completely reconnect again. That doesn't seem right. There is too much overhead in connecting and disconnecting and it would slow down the polling.
So my question is, after I successfully talk to a slave, how do I get xDone to reset so I can get new values from the device without disconnecting?
Am I missing something obvious?
Thank you for your help.
Ken
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After some digging I found that ClientRequest inherits from ETrigTo. ETrigTo states in its documentation that all outputs will be reset on the falling edge of xExecute. This does not happen. I cannot tell from the documenation if ClientRequest overrides xExecute behavior or not, but this is where the issue is I believe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is a great question. Yes and No. The sample is written to talk to itself. Meaning it spins up a master and a slave then they talk to each other in the same soft PLC. When trying to talk to something other than itself the sample is broken and does not work. I'm working on simplified code now to post and should have something shortly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In trying to build a simple sample to post, I also found that once xError is set, that also doesn't reset with xExecute := FALSE. This is specific and only tested with ModbusFB.ClientRequestReadHoldingRegisters; I haven't tested with any of the other ClientRequest* objects.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everyone,
I'm experimenting with the ModbusFB library examples and I've found a strange issue that I think is just my lack of understanding.
I'm able to connect to a slave with my code, but after a successful poll, the xDone is set to TRUE which is correct. BUT, once that happens, ModbusFB will not attempt to talk to the slave again. I have to disconnect and reconnect to get it to talk again. I cannot reset xDone to FALSE.
After I get back xDone = TRUE I set xExecute to FALSE and thought that would reset xDone, but it didn't. The only way I could get new values was to set xConnect := FALSE and initDone := false so that the system would completely reconnect again. That doesn't seem right. There is too much overhead in connecting and disconnecting and it would slow down the polling.
So my question is, after I successfully talk to a slave, how do I get xDone to reset so I can get new values from the device without disconnecting?
Am I missing something obvious?
Thank you for your help.
Ken
After some digging I found that ClientRequest inherits from ETrigTo. ETrigTo states in its documentation that all outputs will be reset on the falling edge of xExecute. This does not happen. I cannot tell from the documenation if ClientRequest overrides xExecute behavior or not, but this is where the issue is I believe.
did you get the example project to work? https://forge.codesys.com/prj/codesys-example/modbus/home/Home/
seems like very strange behaviour, can you share your code?
That is a great question. Yes and No. The sample is written to talk to itself. Meaning it spins up a master and a slave then they talk to each other in the same soft PLC. When trying to talk to something other than itself the sample is broken and does not work. I'm working on simplified code now to post and should have something shortly.
In trying to build a simple sample to post, I also found that once xError is set, that also doesn't reset with xExecute := FALSE. This is specific and only tested with ModbusFB.ClientRequestReadHoldingRegisters; I haven't tested with any of the other ClientRequest* objects.