Polling issue with high register number with Arduino via Modbus
-
Hi copytco, glad that class worked! I was able to get a little more information. Can you try this attached .class in that same location ( com/serotonin/io/serial ) and let me know if it's still occurring?
-
Thanks, I see that there is no longer error message, but some other appeared. Details are here: http://pasted.co/ae06e69d To know if it resolves the aborted polls issue, I would need to let it run for couple of hours.
-
Great! I do not know what you are referring to, "but some other appeared." The only errors I see relate to your meta points having some disabled points in the context. Remember, we turned on debug logging! Please let me know if that fixes the issue for you, and I can discuss the modification I made with the other developers for integration.
-
Thanks, unfortunately I still experience those errors mentioned in the first post. Though, they seem to be a little bit less intensive.
-
How bizarre. Like I said, I think part of the error is from the native portion of the JSSC, so perhaps you could have better luck on a *nix system. It would be nontrivial to troubleshoot this more through the forum. Would you mind providing a couple details? Like, what version of windows are you using? Can you confirm the errors are still from com.serotonin.io.serial.JsscSerialPortInputStream?
My understanding of what I think it going on is that JSSC is reporting an RX event, and then we're requesting to read the number of bytes the event purports to contain. This null would suggest an RX event occurred purporting more bytes than it had (or than are actually in the buffer), which would suggest a deeper problem.
-
I run Mango on Windows 7 Home Premium, on Asus K53S with i7-2630QM CPU. All I know about those errors is that what is in the first post and while going through the log I see also something like that:
WARN 2016-01-15 19:25:18,888 (com.serotonin.m2m2.rt.dataSource.PollingDataSource.scheduleTimeout:106) - Modbus: poll at 2016/01/15 19:25:18 aborted because a previous poll started at 2016/01/15 19:25:16 is still running
DEBUG 2016-01-15 19:25:18,888 (com.serotonin.m2m2.rt.EventManager.raiseEvent:155) - Event raised: type=DataSoureEventType(dataSourceId=2, eventTypeId=4), message='Modbus': Data source with xid: DS_257972 and name: Modbus, aborted 219 polls.I can try to run fresh Mango install on virtual machine with Ubuntu installed and see what happens.
-
Seems like pretty normal conditions. It's definitely experienced heavy use on Windows 7. So, you're not getting the same NullPointerException, or you are? It's certainly possible the Arduino is saying something it shouldn't to the wire.
-
No, this exception no longer occurs. However, timeout errors are still present. I imported the project, after some modifications, to ScadaBR and It works without those errors. Also, I have set up RapidSCADA and It is also going without any timeouts on the same polling time configuration, so this drives me to conclusion, that the issue comes directly from Mango.
-
Hi copytco,
Hmm. Well, ScadaBR is using a fork of the very old Mango. I ran up the old Mango on RXTX to try and test what you're talking about on my machine. My observation was that the adapter I used to convert from USB to RS485 influenced the results I got on the reliability of the connection. Using the circuitry shipped on our embedded product, for instance, I did not suffer any polls aborted. Using a USB to 422/485 hub I had some luck overriding the timing down to 0, but didn't abort many polls either way. The two straight USB to RS485 cables I had on hand revealed one likely broken cable and one that aborts polls semi-regularly. Also, the frequency of data arriving into your database is more important than whether or not polls abort. For instance, if you point a datasource at an invalid port and set the polling faster than a subsystems' timeout on attempting to open the port, you will timeout every time.
I did not experience any significant differences running these tests against a Mango 2.1.3 instance (using RXTX and a more similar Modbus4J to ScadaBR's) vs. running it against the current Mango, except perhaps that the JSSC current version doesn't crash when the serial plug is pulled (thanks RXTX!). You can experiment with the override timing settings, but it is not trivial to actually try to bring a system into compliance with Modbus timing. The device I have on hand has a baud of 19200, though.
-
Hi phildunlap,
I use a simple USB A male to B male cable to connect my Arduino and unfortunately I am not capable of building 485 type of connection.
Any type of timing settings (even above 10 s) resulted in aborted polls in Mango, while as strict polling as 500 ms or 1 s in ScadaBR or RapidSCADA or any other Modbus Master (downloaded some applications acting as Modbus Master) do not act like Mango with the same settings. Therefore, I do not know what type of timing override I might employ to make it work.