@phaedrux said in BlTouch not responding to commands?:
@tjb1 Ideally your printer should be configured to use a left hand cartesian coordinate system
So if the offset is to the left or below the nozzle it will be negative value. If it is to the right or above it will be a positive value.
Thank you, I think that would be a good picture to add to the G31 command in the wiki.
@phaedrux said in BlTouch not responding to commands?:
To get accurate probe results, the Duet needs to know how far the BLTouch is from the nozzle in X and Y. To measure this, place a piece of paper on the bed and use tape to hold it in place. Move the nozzle down until the it touches the paper and leaves a small imprint. Make note of the current X and Y coordinate. Use a marker to make the spot clearly visible. Now jog the print head in X and Y until the BLTouch pin is on the exact spot you marked. Make note of the new X and Y coordinates. The difference between the two will be your X Y offset in the G31 command.
How do you know which sign to use on the offset?
Now that 12864 support is in the firmware does that mean it will work on a Duet WIFI/Ethernet?
@garyd9 said in Firmware 2.02 Release candidate 3 now available:
WARNING: What follows is a WAG. Well, and educated WAG, but still a guess.
I wonder what the actual gcode DWC is sending - in particular if its actually sending a M290 R0 or M290 R1.
I wonder this because there's a commit that appears to be functionally different for R0. Previously, it would call PushBabyStepping(val - current). Now it's calling PushBabyStep(val)
I really don't understand the code I'm looking at, and my initial impression is that this change fixes a bug where the absolute mode (R0) was doing relative changes instead of absolute changes.
You can see what DWC is sending the Duet by opening the Developer Tools for your browser (usually F12), select the Network tab and then click any of the buttons and you'll see something along the lines of http://ip_address/rr_gcode?gcode=
Would this include it randomly falling in the middle of a print or is that a different issue?
I had this same issue with a BLTouch from TriangleLab. It would deploy, touch the bed, retract, and then shoot back out and retract again. It also fell down in the middle of the print several times causing it to keep catching on the print and if it didn't fall all the way it would error out. I tried rewiring it (including pulling the wires away from the stepper/heater wires) and even mode 9 with no success. I don't know if it's because it's a clone or not but I took it off and switched to piezo.
@jul said in Nozzle can't fall to 60°C:
M106 P0 S1.0 L1.0 I0 F500 H1 T60 works well for keeping my fan alive until temperature reached
Thx
As I don't already have my relay, I can't test the M81 command. I'll test as soon as I can
Why do you have the G4 S300 and M116?
@dc42 I would say most of industry is accustomed to Fanuc Custom Macro B and might be a good standard to follow if you are looking for industry support.
Sometimes its a bit convoluted to do loops or proper if statements but it works. Something I use in my programs to calculate a loop variable based on a hole diameter is below
IF[#510NE#4115]THEN#3000=1(LOAD WORKSHIFTS) - #3000=1 is program ending alarm
IF[#504EQ0]GOTO7 - Will skip ahead in program to line N7
IF[#507EQ0]GOTO7
#100=.5
#101=.45
IF[#500GE#100]THEN#3000=1(ORDER HOLE TOO LARGE)
IF[#500GT.35]THEN#101=[#500+.1]
#102=#100-#101
#103=FIX[#102/.012](NUMBER OF PASSES ROUNDED DOWN)
#104=[#102MOD2](EVEN-ODD TEST)
IF[#104EQ0]THEN#105=#103+2(EVEN PASS)
IF[#104NE0]THEN#105=#103+1(ODD PASS)
#106=[#102/#105](NEW DEPTH OF CUT)
#105=#105/2(DOUBLE PASS SPLIT)
and then the while loop that uses it
#107=0
WHILE[#107LT#105]DO1
G1 U-[#106] F6.
Z-1.0
U-[#106] F1.
Z.0625 F6.
#107=#107+1
END1
#100-#199 variables are called common and are typically cleared at program end/reset, this can be changed on some machines by changing a parameter in the control
#500-#999 are maintained between programs and power cycles
#1000 and above are typically machine variables that can be read (and sometimes modified) but these are defined in the Fanuc Operation and Maintenance handbook for the control. On Fanuc 16i/18i/21i (and possibly more) #5021-#5028 will give you the machine coordinate for the respective axis (X, Y, Z, etc...) while #5041-#5048 will give you the workpiece coordinate for the respective axis. In the above sample #4115 is the currently loaded program number.
This is a good reference for Fanuc Custom Macro B that I use at work, it also goes pretty deep into bitwise operations available on Fanuc.
@jul said in Nozzle can't fall to 60°C:
ok for my fan, I will give it a try.
Is there a way to do something when the fan shutdown? I want my printer to blow until 60°C is reached then turn the printer off
You can use M81 S1 per https://duet3d.dozuki.com/Wiki/GCode#Section_M81_ATX_Power_Off or if you aren't using M81 I assume something like the following would work as well?
M106 P0 S0.0 I0 F500 H1 T60 ;Change fan P0 to thermostatic control with 60C target
G10 P0 R60 S60 ;Set tool 0 to 60C Standby/Active temperature
M116 ;Wait for temperature
G10 P0 R0 S0 ;Set tool 0 heaters off - needs confirmed
*Command to shutdown here*
@jul said in Nozzle can't fall to 60°C:
Just for be clear:
P0 (wich I want to wait until asked temperature) is the fan wich blow on my print, so I want to manage speed on the slicer, not themostatic.
But I can maybe put your command in my slicer's end script after M104 S0 ?
Yes if you place M106 P0 S0.0 I0 F500 H-1 in the starting g-code (this is needed in the starting g-code to reset the fan to g-code control if you don't reset Duet between prints) it should allow that fan to be controlled with g-code like a normal print fan then when you reach the end (ending g-code) you should be able to place M106 P0 S0.0 I0 F500 H1 T60 and the fan will stay on until 60C is reached.
@jul said in Nozzle can't fall to 60°C:
@tjb1 Idon't want to modify P1, it works well.
I want P0 to wait until the cold temperature is achieved.
I did that before with Marlin firmware on ramps, and it worked a charmed.
With Marlin, I did M104 S0 followed by M109 R60 and it didn't regulate, just wait as hotend were stop.
The duet firmware doesn't seem to work that way with M109 R60, it regulate
I'm sorry, I didn't edit the commands to reflect the correct pin. Change the P1 to P0. If you use the command to change P0 to a thermostatically controlled fan at the end of the print, it will leave the fan on until it reaches 60C and then shut the fan off but it's not a blocking code and the g-code will terminate.
I changed the text in Quoted Strings and added a note to M98 to reflect this.
@jul said in Nozzle can't fall to 60°C:
@tjb1 said in Nozzle can't fall to 60°C:
Are you using it to cool the print and don't want it running all the time?
Exactly
Try turning thermostatic off in the start g-code of your slicer using M106 P0 S0.0 I0 F500 H-1 which should allow it to be controlled like a normal print fan and then in the ending g-code when you want the fan to stay on until 60C turn it into a thermostatic fan with M106 P0 S0.0 I0 F500 H1 T60
@jul said in Nozzle can't fall to 60°C:
Thanks for helping, but I'm using this on P0 (nozzle) wich I can't use thermostaticaly.
P1 (extruder) is always on and could be in thermostatic mode, but is not noisy
Why can you not use thermostatic mode on P0? I don't see anything in the documentation other than they recommend it on P1 due to it being activated on Duet restart by default.
Are you using it to cool the print and don't want it running all the time?
It doesn't explicitly say where they can be used but there is a section covering quoted strings - https://duet3d.dozuki.com/Wiki/GCode#Section_Quoted_strings
Well I connected to the Duet with micro USB and used the Adafruit TTL on it and was able to communicate over the PanelDue connection so I placed the Teensy on and then the commands started showing up in the Duet and Teensy was receiving information so I removed the micro USB and went back to wall power only and now the Teensy is receiving information? I don't understand why it works now but it does? Thank you David.
It is a Teensy LC which is 3.3v - https://www.pjrc.com/teensy/teensyLC.html
Here is what Serial2 is putting out according to Tera Term and the Adafruit TTL cable - https://i.imgur.com/c7m3XBH.png
I tried this code today with no luck - https://pastebin.com/ETTp8iWy
I tried with bauds 9600, 57600, and 115200. Tried M575 with S1 and S0, and tried Serial2.println() and Serial2.print('\n'). Not getting anything back from the Duet...is there a way to see what the Duet received? I can confirm that the Teensy is sending stuff out using an Adafruit TTL cable with TeraTerm on the computer.
I'm trying to communicate with the Duet over the PanelDue serial port with a Teensy LC (https://www.pjrc.com/teensy/teensyLC.html) but I'm not receiving a response.
I'm running the code here - https://pastebin.com/JF1h1spr
I have this in my config.g - M575 P1 B57600 S0
Am I missing something here? TX and RX are connected to pins 9 and 10 on the Teensy.