Closed just-jason closed 2 years ago
Can please ask, is there a homing or E-Stop type process that needs to be cleared first when in HPGL mode ?
Currently when switching to $HPGL mode an attempt to home the machine is done. If this fails it wil not respond to commands(?). However, since you get the Ready... message you should be good to go. Do you get motion when in "normal" mode and sending G-code?
Sorry , it looks like this was my mistake. I have made some changes to the pin map, and I have the test board working under HPGL. I found the same thing that you suggested, and made changes so that the homing cycle would trigger. This now works
I am trying out the the HPGL template on a Pico. I have used the machine def for the C.ITOH plotter, and modified the pin map for my machine. This is all still mounted on a "test rig" with blinky leds. When I send Gcode to the board in default state , I am getting a response as I would expect, - the leds are blinking and showing motor activity. Once I switch to HPGL mode with
$HPGL
I do have theMotori HPGL v0.03
reply in console, followed a few sec later byReady...
. When I try and send some basic commands likePU1000,1000;
I do not have any activity on the board. I can check the space of the buffer withESC.B
( 1024) so I am fairly sure the board is in HPGL mode and communicating.Can please ask, is there a homing or E-Stop type process that needs to be cleared first when in HPGL mode ?
For clarity, this is all still on a test board, so I do not have any limit , nor other, switches hooked up. For now I am just checking for motor activity. citoh_cx6000_map.h.zip CMakeLists.txt.zip startup.txt
On a small side note,is it possible that some of the #define names for the ports have been changed ? example: In
driver.c
SPINDLE_PORT > SPINDLE_PWM_PORT ENABLE_PORT > STEPPER_ENABLE_PORT and something with KEYPAD_STREAM, but I just commented that out to clear the build error.