Advanced Search

Having got caught up working on fixing 3d printers all day I thought I would try the example given quickly before going home, only to find that I don't currently seem to have a spindle-on signal.

I will look at fixing that tomorrow if I go in to the hackspace

So I've taken a look at the wiring to remind myself of what is going on. Spindle-at-speed comes from the VFD, the relay can switch according to one of 6 values, one of which is "frequency reached". Anyway key point is that as suspected it only ever comes true when the spindle is on.

Is it going to be ok to set spindle-at-speed immediately to zero when the spindle is stopped, or should I be adding a delay?

Something has happened with the latest commits and I can't dig into that now.
Use git and go back to the March 2025 version. f79ad70
git checkout f79ad70
It does have all the same PDOs.
The ESI file wasn't stored in git so need to generate that as well. EEPROM_generator, restore project, write all files.
Write new eeprom, compile and upload firmware to processor.
Should work, it worked here.

Until now i didnt find any solution

Also note that in the EEPROM generator file I removed the field for the DAC converter for spindle control.

I think it's also a function of the spindle-at-speed logic.
If you use the near function with the actual and commanded spindle
speed to generate the spindle-at-speed signal, it will be true even when
the spindle is at 0 speed, and the issue will not arise.

If you can choose from the 3 you listed, DM860 for sure.
It is the only of those 3 that can drive your motors properly.

DM542 Has a better voltage range, but is still small in current output (4A peak).

Here is what I’m seeing regarding specs. Recall, I have 42V and the stepper is listed at 5A.

DM542 2-phase stepper motor driver
* Output Peak Current: 1.0~4.2A (3.0 RMS)
* Input Voltage: +20~50VDC (Typical 36VDC)

DM556 2-phase stepper motor driver
* Output Peak Current: 1.8~5.6A (4.0 RMS)
* Input Voltage: +20~50VDC (Typical 24-48VDC)

DM860 2phase stepper motor driver
* Output Peak Current: 2.4~7.2A
* Input Voltage: +18~60VDC
 

I figured out my issue and posted the solution in this other thread:
forum.linuxcnc.org/38-general-linuxcnc-q...-ngc-m6-remap#333512

tl;dr: Adding a zero-distance G1 move somewhere between a spindle speed change (such as an M5 stop) and the first "real" G1 move in the subroutine appears to bypass the one-time wait for spindle at-speed that normally occurs after any spindle speed change.

Hello everybody!

The 3-axis machine I'm trying to retrofit has a tool setter button fixed on the bed, as well as a spindle Z probe, and I'm trying to make it work (using qtdragon, if that matters). I don't know the length of the probe, and I don't want to use a fixed value for it due to the possible spindle clamping variations, so I'd like to measure it against the tool setter before every probing routine.

In order to do that, I need to move the probe down until BOTH the probe and the tool setter contacts are closed, to compensate for the probe's action distance. In other situations - probing the stock or setting the end mill length - I need the machine to go until EITHER of the contacts is closed.

The issue is, there are no separate HAL pins to feed the tool setter and the probe signals into, just motion.probe-input. I can combine the signals with or2/and2 and it works for one of the scenarios, but obviously not for the other.

How do you folks solve that? I can't imagine I'm the first one with this question, but digging the forums did not produce anything helpful for me.

Thanks in advance!

 

Reviving this from the dead, as I once again ran into this same issue in my tool changer routine.  Clearly, my original "fix" of just not running the spindle in my M6 remap was just a workaround, not an actual solution.  In my tool changer routine, I was (of course) stopping the spindle via M5 prior to changing tools, and this was causing it to wait on the first G1 move.  I'm not willing to change that to a G0 because I don't want the machine slamming tools in and out of their pockets at full speed.

I haven't been able to easily find a crystal clear definition of this in the official docs, but numerous sources have led me to understand that after each commanded spindle speed change (including stop/start), upon encountering the next feed-rate move (e.g. G1, G2, G3 and probably others) the motion controller will wait for spindle at-speed to become true.  This wait will only occur once after each spindle speed change (i.e. subsequent G1/G2/G3's won't wait) and does not apply to rapid moves (G0).

One aspect that made this issue more insidious and appear to be more elusive during troubleshooting is that it doesn't behave the same when commanding things manually via GUI or MDI, versus when running an actual program in Auto mode which contained tool changes.  I'm guessing that whatever internal flag is associated with this one-time wait gets reset each time execution stops after a manual command.

This behavior is logical enough in the context that G1/G2/G3 are meant to be "cutting" moves whereas G0 rapids moves are not.  However in the context of a tool change or probing or similar, a controlled feed rate while NOT cutting is desired, and there is no such thing as a non-cutting controlled-feedrate g-code command in linuxcnc to my knowledge.

Fortunately, I found a way to fake it out:Thankfully, based on my testing, a zero-distance G1 move seems to be interpreted as a no-op but still consumes the one-time wait.

Adding this before the first "real" G1 move in my tool changer routine has eliminated this issue - at long last!

Other thoughts I had on alternative ways to work around this include:
1) add side-channel logic between the motion and spindle controllers that can stop the spindle without actually changing the commanded spindle speed via G-code (M3/M5 or S commands), so the one-time wait doesn't get triggered in the first place.  This could still be sensitive to this issue if the user g-code program happened to trigger the one-time wait just before triggering the remap subroutine(s).
2) add side-channel logic to fake out spindle at-speed (hold it true) for the duration of the subroutine even when the spindle is stopped.
Both of these options seem more risky to me because of the possibility of getting into a bad state in the event of an error in the subroutine and returning to the user program with the normal spindle control still bypassed in some way, but just throwing them out as food for thought...

  The 3000 definitely does not enter OP operating state, I think it is a problem in the config.xml file which I attach.

yes that will only go away when i run terminal halrun and loadusr arduino-connector
it like hal file loadusr arduino-connector not properly load or something

From your error report