Topics created by alankilian

@alankilian said in The wide range of DC42's effects.:

That's why I changed the design to use the variable-voltage DC:DC converter to power regular LED strings. You can reduce the voltage to juuuuuuuust above the forward voltage of the diodes and get a nice dim continuous light that works perfectly in the dark.

It would be better to control the current, not the voltage, because the brightness would then be less dependent on temperature. You can configure the LM2596 to work in constant current mode too, if you can avoid commoning the LED grounds.

This is the other info I was thinking of, from a 1980s system with separate, analog servo drives.

The lookahead / PID is probably easier to replicate from this version:

Servo_Feedforward.png

That's the CNC section of this overall drive system diagram:

ServoLoops.png

The control those diagrams relate to (Heidenhain TNC360) runs everything on a 16MHz MC68000 if I remember correctly, for machines operating with multi-axis interpolation and contouring at accuracies down to microns, but with totally separate servo drives.

In SBC mode too from 3.3beta3.

It looks all nice and clean now.

Thank you.

Glad to hear it!

Can you tell me exactly what you did to solve this? I am having what looks like a similar issue https://forum.duet3d.com/topic/21878/intermittent-z-issues

@thekarlmiller I got the bed from Steve at SeeMeCNC:

From Steve: M307 H0 B0 ; Heated Bed (H2) M305 P0 T100000 B4388 R4700 C7.06e-8 H30 L0 ; Bed thermistor

T100000 is right because these thermisters have a reistance of 100,000 Ohms at 25 degrees C.

But like I said I haven't checked at ALL to see if these are right.

I just fire it up and print.
And then adjust the temps until the parts come out right.

there is this
https://github.com/martinj/duet-telegram

@alankilian said in Blocked endswitch results in mayhem:

I put that in my first post.

👓 I guess I'm blind.

I suggest updating the firmware to 2.05.1 and the paneldue to 1.24

Upload this zip file to the system tab in DWC. Don't extract it.

https://github.com/Duet3D/RepRapFirmware/releases/download/2.05.1/Duet2Firmware-2.05.1.zip

https://duet3d.dozuki.com/Wiki/PanelDue_Firmware_update

Updating the paneldue firmware may help with the stop button.

I write little programs in C that generate GCODE.

I tried to get a simple failing example for HOURS yesterday and I could not get it to happen using a simpler set of GCode.

I'm thinking along the same lines you are that it might be peeling off.

I'll try more experiments again today and post again.
Also with my printer/firmware information. (Which is in my one other post if you're curious enough to look it up.)

See fixes for inclusion in RRF 2.0.5 here: https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md

Bug fixes:
...
M579 scale factors were not applied correctly to G2 and G3 arc moves

Ian

@bot said in Very tiny circles using G2 look fantastic.:

Cool test! Great results! Thanks for doing that. I had actually been meaning to test this out, because I also noticed S3D's complete inablity to generate sensible gcode. Arbitrarily reducing resolution in places, while generating literal E0.0000 commands...

We need a new slicer that takes a solid model (STEP, IGES) and slices into curves where possible, and takes into account user-defined resolution settings.

KISS will be the first I think it already has the support for G2/G3 arcs and is going to get a method of loading IGES/STEP Files directly!

Thanks. I've used that file to verify that the fix works. And it's not your problem, it mine; because one of my principles is that software should behave reasonably whatever input you throw at it. If everyone took this attitude, there would be far fewer security vulnerabilities in released software.