We looked at CanOpen and found it far too slow for sending all the motion commands in a 3D printing application. However, it should be possible in principle to use CanOpen to send configuration commands to a servo drive, then use step and dir to perform the actual motion.

The optimised CanFD protocol we use to send motion commands is designed to support more than 1000 movements per second. This is normally sufficient, however we occasionally come across slicers that generate ridiculously small motion segments, e.g. 10um long. Printing a sequence of those segments at 50mm/sec would demand 5000 movements per second.

@fcwilt
My idiom when programming is that if it takes 10 lines of code to do the job, it will take a further 100 lines of code to stop people doing it wrong and fix errors. 😉

Have you seen this thread by @DigitalVision?

@zapta said in My wish : Inputs debouncing:

@fcwilt said in My wish : Inputs debouncing:

Some things, like filament sensors, would perhaps be best implemented with dedicated hardware.

Is this because their timing need to be consistent?

Yes

The signal out from the sensor may be quite rapid but I've never studied filament sensors that actually monitor filament movement so I have no idea what the signal out actually is.

For things like push buttons operated by a person the response time is not critical and, if I recall, anything less than 250mS appears to be "instant".

De-bouncing in software is going to introduce an unavoidable delay before it can be determined that the input signal is valid and that any bouncing has ended.

If that delay would prevent the input device from working correctly than using hardware de-bounce will eliminate that delay.

Frederick

@DIY-O-Sphere said in New M-code to send a network request:

that it's not required.
You can use the PS_ON pin to switch the printer of.
Or a more current solution....

Thanks for the input. I was hoping to avoid having to turn on a node-red flow when I am printing and not have to buy more hardware but your input made me think around it a couple of more turns and I think I have come up with a workable solution.

I do not have a separate PSU for 5v as I plan to run the board only when the printer is turned on but I do have a smart home controller.

I'll simply activate the node-red flow every time the smart plug for the printer is turned on and turn it off after having ensured the printer is turned off. The smart plug was anyhow needed to shut the printer down when ready and I can also measure the power I consume for printing 😀

@dc42 @theruttmeister I can confirm that the homing does not respect crosstalk, it is causing major problems while trying to home from distant arm positions due to the way homing currently works.

Any of my current ideas in the homeall.g file to combine the X and Y homing does not work such as:

G1 H2 X-300 Y-300 F1000

which sometimes works but depending on the arm position can get funky very quickly...

Yep. Tried it on 3.2 does Not Work @dc42

@PCR said in G30 Question / Feature Request:

Running 3.2 stable.

if i type

G30 X100 Y100 P0 Z-9999

it will probe at the 100/100 with the probe offset in mind

But if it want to home my machine with a G30

G30 X100 Y100

does not probe at at 100/100. It probes at the current location. I suppose thats normal?
So before i home my machine i have to Go to G1 X130 Y100 when my prob offset is -30.

Best

OK back to your question.

It has been suggested more than once that a G30 with no P parameter respect the X and Y parameters so the probe gets moved to the correct XY position, taking into account the probe X and Y offsets.

You can add your voice to this suggesting in the category for firmware updates.

As it stands you have to use a normal G1 command with X and Y adjusted according to the probe offsets.

You can compute the values for X and Y yourself or you can use the conditional code feature of v3 firmware to do it for you - if you wish.

Frederick

@LB

The PID parameters will actually change as you get to higher temperatures (gain and time constant mostly), although it honestly won't affect the heating too in the initial ramp up. I feel uncomfortable ramping more than 3 degrees C / second (which would let you hit 200C in under a minute), especially as temperatures get higher. Using a lower PWM at lower temperatures helps limit the ramp rate, then upping the PWM at a later point in time once you get to a higher temperature.

Overall, I'd just like to build some more margin and safety into the design by limiting the ramp rate without having to adjust by hand (as I've done in the past during heat-up).

@oliof said in Stop Firmware Retract and Pressure Advance from Fighting:

@dc42 what's with firmware retract with z hop? Either way, they seem to be applied directly after another which seems to lead to very noisy extruder back-and-forth.

When G10 is executed, retraction happens first, then Z hop. G11 undoes the Z hop, then undoes the retraction.

if you search the forum you'll find you can use names for imaginary tools or fans/sensors etc as a string variable until support is added to the firmware which is on the road map afaik

@chrishamm so I guess something like this?

echo "Stall detected:" echo " Current position:", move.axes[0].letter, move.axes[0].userPosition, move.axes[1].letter, move.axes[1].userPosition echo " Current object:", job.build.currentObject echo "Rehoming and resuming." G28 X Y