@cakeslob I shared the next revision PCB design here (click Editor Open to view and edit):
oshwlab.com/iforce2d/stm32-pru_copy
That's actually a modified design to what I showed in the video, as yet untested. I ordered some new boards and once I've confirmed that my changes are ok I'll add this to the github readme. fwiw the changes are:
- fix the need for bodge wire seen in the video
- replace TXB0108 level shifter with 74HCT541
- rearrange so that PA9/PA10 (for UART1) are not connected to optocouplers
- link the UART pin of all stepsticks together, to allow Trinamic 'single wire interface' settings for motor drivers
- add a few more solder pads for GND, 5V, VMOT
Regarding the setting of options, it seems to me that this might be possible via HAL files, eg. use a separate .hal file that causes the LinuxCNC component to fill messages with different information, and the firmware to interpret incoming messages differently. Each message would of course include a flag to denote which type of message it is. To change settings, the secondary .hal file (containing a 'setp' to set the message mode) would be included in the .ini file. In settings mode the PRU would simply read settings and store them to EEPROM or some other onboard storage. For normal usage, comment out the settings .hal line from the .ini file. Each configurable setting would need its own 'pin' in the HAL configuration, and the component could cycle around all settings in turn, sending one per message so that the number of settings can grow in future without needing a larger message size. The firmware could reply with the normal response to keep the connection going and avoid e-stop... I guess. Admittedly I haven't really thought this idea through much, so perhaps there is some problem I'm not foreseeing, but I can elaborate on the details more if it sounds interesting.
@scotta First, thanks for all the effort you put into this, not least of which being decent documentation - I know how that can be a pain in the ass
I have two intended use cases for this in the near future, neither of which actually need any GUI.
The first is a little soldering bot which will do the same job over and over, so the main interaction during the course of normal operation is just to press start after placing another PCB into it, this will be a hardware HALUI button. Initially after a power up, it will need to be enabled and homed which I will do via my g-code server but that will not be very often. Occasionally it will need to be jogged into the starting position with HALUI joystick and rotary encoder, then another HALUI button to touch off.
The second application is as a back-end for the OpenPNP pick-and-place controller, so again no GUI is needed. OpenPNP will issue g-code commands over the network as if it were talking to a more typical 3d printer style firmware, which seems to be common with OpenPNP users.
The g-code server was loosely based on linuxcncrsh, you can find more info about it here:
github.com/iforce2d/linuxcnc-gcode-server
Demo video of the headless operation:
