Topics created by dhusolo

@Phaedrux Sunday afternoona

@GeneRisi HTTP: https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests DSF 3.5 supports those requests, too.

@jay_s_uk Go figure I completely forgot to change that. That worked thanks.

@dc42 I was hoping to figure out a way to not have to set min/max speed. Would it be possible to use an open extruder heater port?

@droftarts It simply echoed

M106 P3:4 H2 T20

But you were correct. I was able to get them both to run with

M106 P3 H2 T20 M106 P4 H2 T20

@chrishamm I found an old USB to TTL adapter. I connect the USB to the Duet's RPI USB port.
I've got the it connected by
TTY RX to Pi TX
TTY TX to Pi RX
TTY GND to Pi GND

I have the jumper on the tty in the 3.3v setting

On the pi listening I ran terminal with

cat /dev/ttyS0

On the duet pi I ran

stty -F /dev/ttyUSB0 115200 /opt/dsf/bin/ModelObserver -q -f "heat/**|tools/**" > /dev/ttyUSB0

This is the output
1b9f91b8-d7ee-4900-b6b5-912538fab252-image.png

@dhusolo the object model changed between 3.3 and 3.4 are documented at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-340.

@fcwilt Agreed. I planned to incorporate it in my build and was disappointed when I couldn't use it. However after enough tweaking I think I'm in a better place. Upgrading to the PTFE coated leadscrews helped quite a bit. I also figured out the leadscrew offsets were slightly off. Once I changed the config results started to improve. Even more so after using 4 points to calculate the leadscrew offset. This was my last G32 without the spring steel sheet on.

8bae2ed7-b959-4195-ac48-706a0157e10c-image.png

@dhusolo said in PSON Macro not working as intended.:

Anyone have any ideas what's going on?

Your trigger macro works more or less "by accident", depending on the timing of config.g as @dc42 points out, and depending on the bouncing behaviour of your button. In addition (and as @dc42 says), you forgive the chance to check power before you turn it on, regardless of state, which, in turn, ultimately runs the config.g.

I think you should rework your macro:

wait 50-100 ms for the button to debounce, then, check its state again: if it is open, quit the macro with M99. if ATX power is off, put it on, then, run your config.g else, wait another second or two (whatever you consider a long press), then check its state: if it is still pressed, turn ATX power off.

Depending on your timings (aka "button press habits"), you can add a loop to wait for the button to be released; this would then be called after steps 2. or 3., regardless of which branch you took.

@dc42 Yes
29b0c3c1-5bf1-4009-9726-d603ec4da891-image.png

@dc42 I reran it like you suggested. These are the results

G1 X5 G4 S2 G1 X105 F20000 M400 M956 P20.0 S1000 A0

70e576cc-43b1-487c-aeca-9380c3a239b7-image.png

G1 Y5 G4 S2 G1 Y105 F20000 M400 M956 P20.0 S1000 A0

6970f7e9-520c-47b7-9241-66f17fd42094-image.png

@dhusolo PanelDue uses 3.3V signal levels, Arduino Nano uses 5V. If you use a level shifter then you probably don't need to change the resistor.

@dc42 said in Neopixels Driven off RPI:

I guess it should be possible to use the shared SPI channel and an external gate to drive NeoPixels on Duet 2.

That sounds promissing!
The ext. gate for level shifting?
Do I have to put the request in the firmware wishlist section?

@o_lampe I'm a moderator with the BLV printing community. So anything I do I have to make sure it stays close to the standard BOM. The BOM calls for a Duet 2 WiFi. Eventually we'll move it to ESP8266 but at the moment it's easier to maintain it on an Arduino.

@dhusolo you can leave PA enabled but you may need to adjust the amount for best results.

@dhusolo as @jay_s_uk says thats not possible those IOs work at 5V and can only source/sink a few mA.

There should be no issue running both part cooling fans from out 1 or out 2 at 24V in parallel (obviously with the jumper set for VIN and 24V supplied to the toolboard)

@dc42 That worked perfectly! Thanks

@phaedrux Haha genius. I missed that one. Thanks

@dhusolo
My code was meant as an example.
You need to monitor the pin that your you're using.
i.e the The pin you created with M950 and the P parameter you use in M581.
You have M581 T2 P1 S1 R0
try

M80 ; Power on G4 S3 ; if sensors.gpIn[1].value = 1 ; check if button still pressed M81 ; turn off power

Not sure why you're using M582 in config.g
I believe it will cause the trigger to run as if you've pressed the button.

@dhusolo said in Tool board v1.1 Heater Offline:

@phaedrux Sorry the paneldue status says "Standby" and in DWC the status is "Off".

Running M98 P"config.g" fixes it but I get these warnings

7/30/2021, 12:44:08 PM Warning: Board 20 does not have input handle 3000 7/30/2021, 12:44:08 PM Warning: Board 20 does not have input handle 1000

That's expected. The tool board is saying that the main board asked it to delete some input devices, but the tool board didn't know about the input devices because it had been powered off and on. If you want to avoid those warnings, delete any endstops and GpIn ports that use pins on the tool board before you turn off VIN.

@dhusolo said in Staring macro doesn't behave as expected:

@deckingman Thank you very much sir. That was the answer I was looking for. I'll give it a shot later tonight.

No worries. Just remember that all moves are relative to something. With relative extrusion, the E value will be relative to the last move end position. With absolute extrusion, the E value is relative to when the extruder was last zeroed. If you think about it, when you want to extrude (say) 15 mm of filament, an absolute value would first have to be converted to a relative value which is why it's generally best to always use relative extrusion IMO).

@dhusolo configure two separate fans (so 2 M106 and M950) and then map them both to the tool in M563 e.g. F1:2

@dhusolo said in Toolboard Heater Fault:

Also DWC will report the hotend is in a fault state but it doesn't tell me what the error is

That will be fixed in a future firmware version, perhaps in RRF 3.4.