Topics created by poofjunior

@arnold_r_clark none have reached out to me (or appeared to my knowledge), but I'll be sure to update the wiki and such if one does.

I'll admit that getting everything into kit format was quite some work. Anyone outside the US looking to sell some might find that one way to get started could be a possible collab with the folks at Filastruder.

@zapta thanks for the note! Link is now up-to-date!

@poofjunior Glad it's fixed. On the structure of your config.g file, it's generally best to put each command on a single line or at least on separate lines but consecutively. The reason being that there are some dependencies and orders of sequences. For example the motor mapping must come before any commands which affect those motors. You seem to have got away with it but mapping the extruder motors way later in the file to the axes motors might come back to bite you in the future. I divide my config into sections such as "motors", "sensors", "heaters", "fans", "tools" etc and put all related commands in each section.

@o_lampe said in Standalone Config Snippets:

@deckingman said in Standalone Config Snippets:

Two lugs only give me 4 possibilities. One switch triggered is hot end A, the other switch triggered is hot end B, both switches triggered are hot end C and no switches triggered means no hot end fitted.

Is it possible to run a trigger macro with two inputs? Or do you have to read 'the other' trigger inside the macro and use 'if' conditions to finally start the right macro?

I haven't actually implemented this "hot end sensing" system on my printer yet. The hot end mounts have the lugs but I haven't yet fitted the switches to the carriage. However, I plan to use the same system that I use with the joystick jog control that I have fitted. This uses 4 micro switches and gives me movement in 8 directions depending on which combination of either one or two switches are closed. There is also a button that when pressed, gives my long moves (about 20mm) and when not pressed gives me short moves (about 0.5mm). So 8 move directions and two "speeds" (actually distances) giving 16 combinations from 5 switches. Essentially it's a single macro which uses conditional gcode to sense the status of the 5 switches. It runs a loop and repeats as long as one or more switches are closed. Here it is in it's entirety which should show how it works.

; ******Trigger 5 - Joystick lefgt,right, forward or backwards ******** ; IO Pin to switch connections J5=left, J6=Right, J7=Forward, J8=Backward if state.status != "processing" ; make sure that a print is NOT running G91; Set relative M400; wait for any moves to finish G1 F3000 ; set feedrate to 100mm/sec M118 S"Trigger 5 - Joystick" while sensors.gpIn[5].value=0 | sensors.gpIn[6].value=0 | sensors.gpIn[7].value=0 | sensors.gpIn[8].value=0 if sensors.gpIn[5].value=0; joystick left if sensors.gpIn[7].value=0 ; joystick left and forwards M400 echo "Left and forward" if sensors.gpIn[4].value=0 ; check for long move button press G1 X-20 U-20 A-20 Y-20 V-20 B-20 else G1 X-0.5 U-0.5 A-0.5 Y-0.5 V-0.5 B-0.5 elif sensors.gpIn[8].value=0; joystick left and backwards M400 echo "Left and backwards" if sensors.gpIn[4].value=0 ; check for long move button press G1 X-20 U-20 A-20 Y20 V20 B20 else G1 X-0.5 U-0.5 A-0.5 Y0.5 V0.5 B0.5 else ; joystick left only M400 echo "Left" if sensors.gpIn[4].value=0 ; check for long move button press G1 X-20 U-20 A-20 else G1 X-0.5 U-0.5 A0.5 elif sensors.gpIn[6].value=0; joystick right if sensors.gpIn[7].value=0 ; joystick right and forwards M400 echo "Right and forward" if sensors.gpIn[4].value=0 ; check for long move button press G1 X20 U20 A20 Y-20 V-20 B-20 else G1 X0.5 U0.5 A0.5 Y-0.5 V-0.5 B-0.5 elif sensors.gpIn[8].value=0; joystick right and backward M400 echo "Right and backwards" if sensors.gpIn[4].value=0 ; check for long move button press G1 X20 U20 A20 Y20 V20 B20 else G1 X0.5 U0.5 A0.5 Y0.5 V0.5 B0.5 else ; joystick right only M400 echo "Right" if sensors.gpIn[4].value=0 ; check for long move button press G1 X20 U20 A20 else G1 X0.5 U0.5 A0.5 elif sensors.gpIn[7].value=0 ; joystick forwards only M400 echo "Forward" if sensors.gpIn[4].value=0 ; check for long move button press G1 Y-20 V-20 B-20 else G1 Y-0.5 V-0.5 B-0.5 elif sensors.gpIn[8].value=0 ; joystick backward only M400 echo "Backwards" if sensors.gpIn[4].value=0 ; check for long move button press G1 Y20 V20 B20 else G1 Y0.5 V0.5 B0.5 else break else break

@phaedrux I am very excited for it! Thanks for the heads-up.

@poofjunior said in HTTP API for Standalone Duet 3 Mini and Duet 2:

(1) for commands where I'm extracting data (M409), I need to follow up with rr_reply to actually collect it. Versus with DSF, it's part of the response when posting to /machine/code.

Use rr_model in preference to M409, than you will get the reply as part of the response

And (2) after sending a small sequence followed by "M400," I couldn't find a way to tell my code to wait until the machine was actually done. Versus, with DSF, sending M400 causes the http response to hang until the moves have actually finished.

You can use rr_model to query state.status and watch for it to change from Busy to Idle.

Have you seen this thread by @DigitalVision?

@whopping-pochard Wow--good eye! Yeah, it was in the B-Sides article!

So just to get this right: You want to move to a certain position in a macro file, call some arbitrary code to switch something on/off and then resume movement?

That's mostly right! I wasn't planning on doing this from a macro, just by simply sending a stream of GCodes on the socket connection.

Huh, this is a clever solution, and I might play around with it. But, now that you mention that the object model synchronization isn't real time, it may be that I'm simply building this application on top of the wrong interface. Something as simple as getting an "OK" from an M400 from an interface that invokes the motion planner would be totally sufficient.

Thanks for pointing me in the right direction!

I don't think there's a huge need to be strictly in that direction.

If the documentation mentions that the prior machine state is both saved and set as the starting point upon entering a macro, then folks should be able to work from that. Knowing this now, in my case, from now on, I will prefix all my macros with G/M codes that enforce the machine state that I want to work from when entering the macro.

Many thanks for clearing this up! I'll dig through the DSF docs for the primary "Code" packet syntax in the long term and ask away with questions if something comes up.

I've just realised, I just need to wait for variables...

Use object model to get value and assign to variable. Make changes/run script, and then use variable to assign the previous values.

Nothing to see here! As you were! 🙂

I'm very poorly versed in python. Perhaps due to my ignorance of all the subtleties of programs written in python, I was constantly deleting files I needed or writing dumb code.

@poofjunior I do my move out in TpostN.g and use G53 to ensure the move out can use the same coordinate system as TpreN.g

That means you can extrude in TPost to purge before you move out.

Whoop--I have fixed my own problem. These files were missing because the projects were not inside of the workspace folder created by Eclipse but instead located elsewhere, so they were compiling individually without issue but couldn't link.