Replies: 4 comments 28 replies
-
|
Is the Pi at the generator or a distance from the generator? What wires are you running from generator to ground? Are the wires twisted pair? |
Beta Was this translation helpful? Give feedback.
-
The pi is about 100ft away from the generator -- indoors on UPS protected power.
|
Beta Was this translation helpful? Give feedback.
-
|
I would expect that wiring to be ok as well, and it is well underneath the max length for RS485. Hopefully jgyates' answer gets you on a path to success, I'm not sure what else to suggest. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @zinglo The errors in myserial.log indicate that there is an issue with serial port availability, possibly another process using the serial port or a power issues. Power issues would likely fall in to two categories (too much current is required from the USB adapter or the pi power supply is under rated). A few questions: Does the RS-485 adapter have a setting or jumper for a terimination resistor? Since you only have 2 devices (the pi and the generator) the terminator resistor should be enabled. If you had more than 2 devices you only want the resistor active for the first and last devices on the RS-485 bus. What is the rated current output of your AC power supply? Is anything other than genmon running on the pi? What is the output of this command: cat /boot/cmdline.txt What is the output of this command: and The flags in the "vcgencmd get_throttled" command are reset on every boot so make sure you are reading this after your get the timeout errors. You could test to see if you still get the errors when the USB RS-485 serial device is not connected and use the built in serial port but just do not connect it to your generator. You will still see timeouts but use the built in serial port error should not appear unless something is trying to access the port. |
Beta Was this translation helpful? Give feedback.
-
|
As another thought, since you said it works intermittently, perhaps you could try running it right at the generator temporarily, or permanently by swapping the use of the cat5 from RS485 to be Ethernet. That would give an opportunity to rule out the length of the cable being a problem for RS485. Given the logs you posted, you could potentially power the Pi off a battery pack for a couple hours and see if it's stable or not. |
Beta Was this translation helpful? Give feedback.
-
|
If you have outbound email enabled you can submit your log files form the About page and I can take a look. I am curious if the timeout errors correspond with the errors in myserial.log timestamp. |
Beta Was this translation helpful? Give feedback.
-
|
@jgyates Logs sent. I suspect this is going to be a "punt the usb" situation and I'll end up going with the transparent rs485->tcp/ip device. |
Beta Was this translation helpful? Give feedback.
-
|
@skipfire That's going to be my next debug. I can easily drag an extension cord out to the generator and plug in the pi with a short/larger gauge wire. I'm in a time crunch for a couple of other projects so... hopefully in the next day or so. Thanks for the help. |
Beta Was this translation helpful? Give feedback.
-
|
I just noticed I typo'd an incorrect gauge, I'm using 16awg, not 6, 6 would be huge! |
Beta Was this translation helpful? Give feedback.
-
|
This page has an example python script that will log serail USB device insertion and removal events. I tested it and made a small mod to include all types of events. You would need to install one python library listed in the link: https://askubuntu.com/questions/1461546/continuously-monitor-usb-connection-status attached is the modified python script. Hopefuly this would allow you to see if the USB device is being ejected and reinserted due to power issues. I have to zip the file since github will not allow python extenstions as an attachment. Let me know if you have any questions. |
Beta Was this translation helpful? Give feedback.
-
|
Just a suggestion, maybe see if there is a firmware update? I went back and looked at some of the past genmon logs that have been submitted from other Briggs users. I am not seeing any intermittent timeouts or have I heard of this type of issue before. It is really odd. I am not sure this will get is a lot of data, but it may provide some insight into the frequency of the errors. The modbusdump.py program can be use to read modbus registers over both serial or TCP. https://github.com/jgyates/genmon/wiki/1----Software-Overview#otherappsmodbusdumppy for TCP, a command line like this: this would read serial: sudo python3 modbusdump.py -r 9600 -p /dev/ttyUSB0 -a 2 -s 1 -e 86 -f -r 9600 -b 1 -x 2 If your pi is running the latest version of raspberry pi OS then you are likely in a managed python enviroment so you would need to run modbusdump in the virtual python enviroment if you are. This info is located here: https://github.com/jgyates/genmon/wiki/Appendix-S---Working-in-a-Managed-Python-Environment Let me know if you have questions. |
Beta Was this translation helpful? Give feedback.
-
|
I dumped 4-5 times a few seconds apart. One run was error free. Dumb question but... is there any flow control? I know there is no hardware flow control with just 2 wires, but is there any Xon/Xoff equivalent? I see no way to enable it... but it almost feels like a flow control issue where one side is enabled and the other side is not. `(genenv) root@genmon:/usr/local/genmon/OtherApps# python3 modbusdump.py -i 192.168.47.10 -t 8899 -a 2 -s 1 -e 86 -f Modbus Timeout Error(s) detected: 2 Program Complete Modbus Timeout Error(s) detected: 2 Modbus Timeout Error(s) detected: 3 Modbus Timeout Error(s) detected: 1 |
Beta Was this translation helpful? Give feedback.
-
|
Well that is not very enlightening. No flow control. This is throttled by the the fact that modbus supports a single transaction at a time. For example, genmon ask for a register via modbus and it will not ask for anoher until a timeout occurs or a response packet is received. As a test I guess it could not hurt to go to the genmon advance settings and set the Additional Modbus Timeout to a much larger value, like 10, and see if that makes any difference. In theory it could be sending the response to quickly, but I haven not seen that on any other Briggs units. Since RS-485 is two wire and half duplex medium only one device and transmit at a time. When a given node is not transmitting it must put the transmitter in a tri-state / high impedance state so another node's transmitter can drive the line. The disabling of the transmitter is typically automatic and handled by the RS-485 adapter. I think the odds of this occurring are low, but you could poke around the settings to see if there are any timing parameters related to the communication on the controller. There is a snipit from the log file mymodbus.log your submitted earlier: 025-02-05 08:36:29,550 : Error Receiving slave packet for register 00b6 This discarding bytes message is extra data that is not expected. The "Buffer = [0x02,0x32,0xc1]" is a partial data packet that was received once the timeout occurred. Genmon can talk both modbus RTU (serial) and modbus TCP. Modbus serial is always RTU an if you use the PUSR gateway it should still be modbus RTU since the controller is still communicating serial. The gateway should be just wrapping the modbus RTU in a TCP socket. RTU has a minimum response size of 6 bytes for a requested packet and it looks like genmon is receiving 3 bytes when the timeout occurs. Why there is a lot of extra hex 13s is a bit of an unknown. Typically RS-485 has a setup of pull up / pull down resistors on the list to put it in a know state when no node is transmitting. Some RS-485 adapters have the ability to disable these pull up / pull down resistors. Not sure if that is what is happening here or not but the discarded byte is not expected and I do not see this in the logs of other briggs units. You may want to look a the mymodbus.log file in that modbusdump.py outputs (it is in the same directory as the program) and compare it when you do a serial vs a TCP run. Not sure that will give us a great deal of data, but I am just trying to hone in on what is happening on the line to cause these errors. |
Beta Was this translation helpful? Give feedback.
-
|
FYI a proper response should be something like this (in hex): 02 04 02 xx xx yy yy This is a buffer of [0x02,0x32,0xc1] does not make a lot of sense other than the 02 at the beginning. In theory modbus exception packets can be sent back but that would logged as a different type of error and the type of exception would be logged as well. |
Beta Was this translation helpful? Give feedback.
-
|
Just curious if a solution ever came up to this? I am using the same USB/serial adapter for my setup, Briggs 26kW with 1032 controller. My pi is at the generator getting its power from the 12v supply via a 12v to USB-C adapter. I am seeing the same buffer error as above in the modbus log. Timeout % errors are roughly 4-5% on the monitor tab. |
Beta Was this translation helpful? Give feedback.
-
|
I never found a proper "fix." I have a constant 4.5% error rate. I pretty much worked every angle and replaced or re-routed every component except the generator controller itself (or some modifiable parameter there). I used 2 different interface methods, different cables... constant 4.5%. |
Beta Was this translation helpful? Give feedback.
-
|
This just a guess, but it would fit the data. Genmon continuously polls the controller for modbus data. Since the error rate is constant at 4.5%, to me this implies that the controller is intentionally not responding to modbus data requests during this time. This could be due to a limited set of processing time (or poorly designed software architecture). You can design a cheap system with a single threaded microcontroller, but good software can potentially allow serial comms to perfom uninterrupted with the help of a timer to simulate task switching to allow the comms traffic to flow. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Checklist
Version
Controller : Briggs & Stratton GC-1032 Controller
Generator Monitor Version : V1.19.05
Pi Model : Raspberry Pi 3 Model B Plus Rev 1.4
OS Name : Debian GNU/Linux
OS Version : 12 (bookworm)
Have you submitted your log files from the About page? Note that outbound email must be working for logs to be submitted.
I have not submitted logs
What is/are your question(s)?
Warning: While I am on old retired IT/unix nerd, I have zero experience with RS485. I suspect my issues are related to my ignorance.
I have a brand new genmon install connected to a B&S GC-1032 controller. The connection is via cat5e of approximately 100ft. I used orange/orange-white pair for A/B and green for ground. I've set the serial settings to the settings on the 1032 controller (9600,even,slaveid 2).
On the pi side, I am using a USB to RS485 adapter (https://www.amazon.com/dp/B081MB6PN2). The pi is powered by AC/UPS power inside the house.
My comms comes up, but it bounces up and down. Genmon appears fully operational. I consistently have a Red warning icon/bar at the bottom of genmon with "Genmon system warning: not receiving data". If I watch the monitor tab, the Generator Monitor Stats: Monitor Health field toggles back and forth between "Not receiving data" and "OK." Communication stats show a constant ticking up of "Timeout Errors".
I'm not entirely sure where to go from here and could use some suggestions. (You may have to talk to me like I am 5.) My next thoughts are either physical cable problem or some sort of compatibility issue with the USB dongle.
I did check for throttled/undervoltage per the serial trouble shooting. Possibly this suggests my USB dongle was a poor choice?
/var/log/myserial.log snippets:
Additional information
No response
Beta Was this translation helpful? Give feedback.
All reactions