Activity for kbus
-
kbus posted a comment on discussion Forge 🇬🇧
To be more specific, trying to reset xError on ModbusFB.ClientRequestReadHoldingRegisters once it gets set.
-
To be more specific, trying to reset xError on ModbusFB.ClientRequestReadHoldingRegisters once it gets set.
-
Have another issue. I cannot reset xError once it is set. Does anyone know how to reset xError after it is set?
-
Say I want to connect to a modbus tcp device, then want to disconnect after reading. What do I call to make it disconnect? I've tried setting xConnect := FALSE; but that doesn't work. I've implicityly set ~~~ _Connect := false; ~~~, and that doesn't work either. In all cases the .Connected is true.
-
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.
-
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.
-
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.
-
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...
-
Quick correction to the workaround code above if anyone needs it. The line between the implicit on and off should set the internal private variable. {implicit on} server._uiPort:=28502; {implicit off}
-
Thank you very much Ullrich. I appreciate the quick turn around. You guys are awesome. Ken
-
Sorry, I should have posted here. I'm new to the forums. Please see my post below about a potential bug. Thank you for any help you can give. https://forge.codesys.com/forge/talk/Engineering/thread/e8deaefc16/ Talk Topic about project #codesys-example/modbus
-
Found something more that indicates this might be a bug actually. when expanding the object in the watch window I see that the public uiPort variable is set, but the private internal uiPort is still 502. Is this a bug maybe?
-
Hello, Using the example project ModbusFB I'm able to run the project as a modbus slave and connect and read just fine if I use port 502. However, if I use an alternate port, it still uses port 502 and I'm unsure why. If I exclude the uiPort option it uses 502. If I add the uiPort option as below, it shows it is set as 28502, but I cannot connect to that port and can still connect to port 502. Any idea of what's going on? serverTCP(fcsSupported:=fcsSupported, dataModel:=tableDefs, wsInterfaceName:="",...