I have a VFD wired to a mini-rambo (marlin FW) and working great in testing. M3 is CW, M4 is CCW, and M5 is stop.
However, when a g-code program commands the spindle on, it ALWAYS turns CCW. It doesnt matter if the program calls for M3 or M4. Anyone ever seen this before? I have been driving myself NUTS with a burning wood issue ALL DAY, only to find out the spindle is reversed. Again, it works perfectly from terminal, I had NO reason to suspect it.
G1 move commands will not obey the feedrate. G3 moves will, but once I am out of my ramp and into my cut, the feedrate goes way down, even though the program is calling for the same feedrate.
Please help, banging my head against a wall and WASTING my saturday!
#define SPINDLE_LASER_PWM_PIN 9 // Hardware PWM #define SPINDLE_LASER_ENA_PIN 70 // Pullup! 18 was default #define SPINDLE_DIR_PIN 71 // 19 was default #define SPINDLE_REV_PIN 85 // Line added as a test to work with VFD
EMI/EMF noise? yes the spindle and the x motor cables run in the same chain, but so do Z and Y
#1 is solved. I had Pin 85 assigned to one of the E0 extruder pins. Not sure if that was default or I was using it as placeholder before I assigned it to Reverse.
so here are 30 lines, which include the transition from the ramping section to the adaptive clearing toolpath. The code was generated by the Marlin post in F360:
These are very small movements. The controller has a limit to how many commands it can execute per second due to the communication (or loading from the SD card, which is somewhat faster).
It depends on the controller but I had estimated a limit of about 20 commands per second I think.
I would try adjusting the generation on the CAM side to use a lower resolution so you get fewer, larger segments.
Makes sense. What kind of tolerance value do people use for adaptive tool paths in fusion? I think the default was .004, but I was getting really jerky motion at first so I lowered it. Guess I went too far.