Hi.
I'm having problems connecting the Swapper to the Raspberry Pi.
The connection was only possible once, now I can't connect it anymore via the plugin.
Switched from the RasPi to my computer and the Arduino IDE.
After some debugging in the firmware I could reduce the cause to a parity check error.
I modified the Arduino code to tell me via lcd and serial port the connection status and what he received from my computer.
When I send 'octoprint' which should initialize the Swapper, I get the same message back via serial, but also the message 'Parity check failed1'.
I get this message every time I send anything.
Also sometimes I get this error sent over serial about a dozens of times in a row, but the return message then is empty (no string or char).
So I assume the Uno is not dead, but there seems to be a bug in the parity check function.
I will continue with the debugging tomorrow.
Anyone here with similar problems?
Note: I added a white space to the serial string output. In the original code there is no space after the colon.
Update: I added a CRC library to the code. 'octoprint' returns a DEC 177, 'swapper' a DEC 43 and so on.
Checked every result with an online CRC calculator and it works fine.
So the parity check is either not correctly implemented or there is a bug in another function since the sent string is received and processed correctly.
Update Update: Looked into the OctoPrint Plugin code. There you see that you have to add the parity bit to your message.
Now the Uno responds correctly.
Still there is no connection possible on the Raspberry Pi 🤔
@extrudercat there is a know issue mismatch between the uploaded octoprint and the firmware for the uno. It will be fixed next.
@bigbrain3d Thanks for the response.
I already forked your GitHub repositories and rewrite most if the code.
The setup firmware is now merged together with the normal production version. Also you can now optionally do the calibration over the USB serial connection. I will modify the OctoPrint plugin and also write a separate tool to callibrate the servos.
The "stutter" bug (serial connection got flooded with empty responses sometimes) is fixed and you can still use the lcd keypad to callibrate everything (I took the calibration procedures out of the button reading switch case construct and added them to separate functions. The buttons and serial commands now can access them indiependently.)
Changed most of the EEPROM write() commands to update() since writing the same values for the 7 not modified servo offsets everytime reduces the lifespan of the memory significantly. Only if the values are out of bounds (less than 100 and more than 140) the normal write command is used.
Also I'm working on a state machine sollution to perform a selftest of the unit after startup and in normal mode remove any chances of collisions.
I will keep you informed when the modifications are done 🙂
@extrudercat that's sounds really interesting. Please let me know when you've checked in your changes, I'd love to review and see how you solved those issues.
sneak peek for serial testing and calibration:
Get device values from EEPROM (if available)