terjeio
commented
2 years ago Originally I was thinking that the Teensy behaved like the arduino and that the USB serial would be replicated on the serial port by default, so I could just send some basic jog commands from the Pi when the Laptop wasn't connected, and move the machine.
Teensy has the USB stack on the MCU, not on an external chip as you have found out. However, a plugin can do all kinds of stuff by maniuplating function pointers including modifying how streaming is handled. Replicating the output should be easy, in the plugin init function save the (relevant) HAL stream pointers, call the serial init function (this returns a struct with pointers to the serial stream functions) and save away this too. Add output functions to the plugin and update the HAL with those, in these call the functions in the saved away pointers and you are good to go:
#include "grbl/hal.h"
#include <string.h>
static io_stream_t usb;
static io_stream_t serial;
static void my_write (const char *data)
{
usb.write(data);
serial.write(data);
}
static void my_write_all (const char *data)
{
usb.write_all(data);
serial.write_all(data);
}
void my_plugin_init (void)
{
memcpy(&usb, &hal.stream, sizeof(io_stream_t));
memcpy(&serial, serialInit(115200), sizeof(io_stream_t));
// hal.stream.write = my_write;
hal.stream.write_all = my_write_all;
serial.write("Hello!" ASCII_EOL);
}Handling input is not that easy, IMO intermingling usb and serial data is not a good idea. Attaching a function to the foreground process (via grbl.on_execute_realtime) is better. From that read the serial input and submit it for processing. There are two methods you can use for that:
- Buffer the input up to a newline and submit it via
grbl.enqueue_gcode(). This is a relatively safe way to do it as commands are only accepted when the controller is in Idle, Jog or Tool change states. - Enable the keypad plugin and send single character commands to it, many commands are supported including jogging. Send input to the keypad_enqueue_keycode() function. For jogging a jog cancel command,
0x85, must be sent on key up to terminate jogging.
Note that real-time commands are handled differently from regular input, you'll have to redirect those separately by calling serial.set_enqueue_rt_handler() with the function that is to receive them.
Does this sound like a reasonable way to do this? Or would it make more sense to somehow enable bidirectional communication on serial2 when the USB isn't active and just talk directly to the grblHAL core that way as if it was just another sender?
The issue here is to detect "USB not active" - it can be done by listening in to real time commands from it and if quiet for a certain amount of time let serial take over control? IMO the methods above is better as it allows jogging even when USB is in control.
It can be noted that I have made a driver level protocol that allows stream switching via handshaking over a pin, the downside to this is that it requires sender cooperation. BTW the Teensy driver does not yet support this.
Another option available for the Teensy is to connect via the second USB port on Phils Pro board and add code support for that. It would be nice if someone would tackle that challenge...
5ocworkshop
I often find myself in the shop and needed to jog the machine to get the gantry out of the way, but if I'm cutting on the machine I don't take my laptop out with me.
I'd like a way to move the machine in a limited way from buttons or a joystick etc. without having to get my laptop and fire up the sender.
On the grblHAL2000 board there is a RaspberryPi header that includes connecting the UART on the Pi to Serial2 on the Teensy. Originally I was thinking that the Teensy behaved like the arduino and that the USB serial would be replicated on the serial port by default, so I could just send some basic jog commands from the Pi when the Laptop wasn't connected, and move the machine.
It turns out the Teensy does not mirror the USB serial communications on any physical serial pins by default.
I'm thinking of using the Pi on serial2 on the Teensy and a plugin, perhaps, to allow jogging but I'm unsure of the best way to do it. I would like to be able to use something like a USB IR remote (that I have a few of) on the Pi side and maps those key presses to various GCODE and grbl commands. Does this sound like a reasonable way to do this? Or would it make more sense to somehow enable bidirectional communication on serial2 when the USB isn't active and just talk directly to the grblHAL core that way as if it was just another sender?