The System
- Raspberry Pi 3B loaded with JMRI (a model rail control and user interface application)
- Arduino 1; Mega 2560 3B + Motor Shield loaded with sketch to control locomotives
- Arduino 1 is connected to Pi USB with separate DC to Motor Shield
- Motor shield is connected to model rail track
- Arduino 2: Nano +Sensor Shield loaded with sketch to control the layout points, sensors etc
- Arduino 2 Sensor Shield is connected to PCA9685 board (SCL/SDA)
- Arduino 2 Sensor shield is connected to PE sensor board
- Arduino 2 is connected to Pi USB with separate DC to Shield and PCA board
- User access to Pi via VNC on MacBook Pro
Current Operation
- Power connected to all devices
- Pi starts up
- VNC connection to Pi established
- lsusb command shows USB connections to both Arduinos
- Arduino 1 shows green and orange steady leds
- Motor shield shows no leds (none exist as the only leds are to show power to rail tracks)
- Arduino 2 shows green and orange steady leds
- Sensor shield shows red steady led
- PCA board shows red steady led
- PE sensor board shows no led on but glows red when placed in darkness
- JMRI Panel Pro application now opened
- In addition to previous led indicators a second orange led flashes slowly on both Arduinos
- lsusb still shows both USBs connected
- JMRI PanelPro app operates as normal but no sensors, servos, or motors are accessible
Working Temporary Solution
- Close JMRI PanelPro app
- Disconnect and reconnect both USB cables
- Restart JMRI PanelPro
- All JMRI functions now operate correctly
The Problem
All of the equipment is to be located under a model rail layout and the thought of crawling under to disconnect and reconnect the USB cables every time the layout is run is not attractive (nor good engineering)
Final Solution
??? Any help would be greatly appreciated
1 Like
Hi Toni,
Thanks for jumping onto the forum! I believe I’ve discussed this problem with you myself earlier this week. Just to make sure we’re on the same page, was this the JMRI application you were running?
https://www.jmri.org/help/en/html/apps/PanelPro/
Also, if you just press the reset button on the Arduino rather than disconnecting and reconnecting the USB type-B cables does it have the same effect? I suspect what may be the case here is that the serial port is already busy with some other running process (not 100% sure what that would be, but in step 12, it sounds like the Pi is still running some type of serial communication with the Uno/s).
Try throwing Serial.end()
before the Serial.begin(baudrate)
in your script and pressing the reset button to ensure that the serial connection is properly closed and then initialized with your Pi between runs. If this does turn out to be the case, we may be able to determine a way to force close this connection from the Pi if it is no longer necessary which would be the best option.
1 Like
Thanks Bryce.
Yes that is the JMRI PanelPro app I use.
Pressing the reset buttons does not do the same as reconnecting the USB cables, i.e. fix the problem
Putting Serial.end() in front of Serial.begin (…) compiles both programmes but when uploading they both give the repeated error messages
‘error in upload. avrdude:stk500v2_getsync():timeout communicating with programmer’.
With this upload failure I cannot move onto your next test!
Toni
1 Like
Hi Toni,
I was expecting that to throw an error, can you please upload your code here so we can take a look at it? (you can add it between two sets of ` with cpp after the first three as seen below)
//Your code will appear like this:
void setup()
{
Serial.begin(115200); // etc.
}
```cpp
Add your code in the gap
```
You’ll need to get rid of that Serial.end();
so that your code compiles and can be uploaded to the board. Also, what results do you get when calling lsusb
from the command line on your Pi. Are you able to send through the output you’re getting on the CLI here?
If you can also try running
ps -ef | grep tty
On your Pi while your application is running, and before you perform your disconnect and reconnect of the USB connections to see whether the serial connection to each Arduino exists. If it does, we should be able to call a kill on its PID (Process ID) to force the connection to restart when your application runs rather than having to disconnect and reconnect your USB connections every single time that your application needs to restart.
1 Like
Bryce,
Before I check out the answers to your questions I’ve just noticed that the two boards have different baud rates both in JMRI and in the Arduino sketches. Could this be important ?
Could you check please I thought I sent the sketches to you in my earlier email with the photo.
Stay safe (my son lives at Paterson!)
Toni
1 Like
Hi Toni,
Possibly, although I have no idea how it’s worked so far if they’re trying to communicate on different baud-rates as the serial communication would be completely scrambled, definitely something to look into though. Killing the process with the serial connection to the Uno from the Pi and restarting it should have the same effect as removing the USB connection and plugging it back in again, except that power will be maintained to the board.
I’m actually not at work in Newcastle due to the restrictions at the moment. But if you let me know where you pulled the code from originally I should be able to track it down and get it added here for you, that way other members of the community can see it and look through any potential issues too.
1 Like
Hi Bryce
OOPS I should have eliminated things which do work when the USB connections are re-set.
The sketch codes are available from :
https://dcc-ex.com/download/commandstation.html
https://github.com/LittleWicketRailway/CMRI-Sensor-Servo-Hub
Toni
(Attachment CMRI_Turnouts_and_Sensors_Part1.ino is missing)
(Attachment CommandStation-EX.ino is missing)
1 Like