Its also [possible the BLtouch wiring is picking up interference from other wiring that runs parallel to it. If your wiring is nice and neat and bundled together, this could be happening. I had problems with my motor wires in this way. For me, moving the wires around in the bundle so they were not running so close for so far solved it.
Posts made by mikeabuilder
-
RE: BL Touch Deploying but Always Triggered
-
RE: Z offset using probe . getting it right . help needed
@Richard-F The important concept about Z-offset is that it the same for every location on the bed of your printer. It's purpose is to tell the firmware the distance between the nozzle and the bed when the Z-probe "triggers". This way, when your slicer tells the printer to go to something like Z=.2mm for the first layer, it will know where that is.
The picture you included is a visual representation of how flat and level your print surface is. The probe measures the distance to the bed at multiple locations (16 places, in your picture). Once the mesh has been created, the firmware will use the data to make small adjustments in Z to keep the tool at the right height above the bed.
-
RE: great prints with PLA, but terrible with pre-foamed LW-PLA
When you solve this. please be sure to post what it was that worked.
-
RE: Storing current tool number across power cycle/ system restart
@SamKudarauskas - DC42 has the failsafe method - an input to the Deut3D board that is triggered when a tool is in its dock. You'd also really want one on the carriage to tell you that a tool is mounted on the carriage. Then on power up, you can run a macro that asks if the switches tell you there is a tool on every dock and no tool on the carriage - normally expected state. If you found a tool on the carriage and only one dock missing a tool, you can infer where the tool goes. You run into a challenge if there is a tool on the carriage, and either more than one tool dock is empty (or none are). You should have a plan for that too.
The less-good way is to track which tool is on the carriage in a way that will survive a power cycle or emergency stop/restart. One good way to do this is to have a line at the beginning of each tpostN.g file and at the end of tfree.g that looks something like this:
echo >"0:/sys/which_tool.g" "global current_tool =", {state.currentTool}
I'm not positive the RRF fw has "-1" in State.currentTool at the end of tfree, so you should check. If it still has the "previous" tool number, then the tpre line should explicitly assign -1 to the global.
echo >"0:/sys/which_tool.g" "global current_tool =-1"
When this line runs, it creates a small macro file called "which_tool.g" in the sys directory, and overwrites any existing file. If my syntax is correct, when the which_tool.g file runs it'll create a global variable called current_tool with the last tool number in it.
Now you insert a line in your config.g
M98 P"0:/sys/which_tool.g"
At power up, the macro runs and creates the global variable. Now you can query it and know which what the last tool that was used. Of course. if the tool fell off the carriage, you won't know that unless you implement the switches above.
WHen this is
-
RE: how to join wires together?
My big secret is to tin the wires first. After stripping the wires, apply some flux so the solder will stick easily and tin the wires. I like flux pens like these: https://www.amazon.com/Soldering-Electronics-Tabbing-Welding-Maintenance/dp/B0953NGKXR. TInning without flux is a big pain. And the pens are great for working on PC boards if you do that.
Once both side have been tinned, the two sides will stick quickly. And use heat shrink tubing.
Not quite related, but if you expect the wires to be flexed at all during use, I highly recommend silicone insulated wires. The insulation is flexible and usually the strands of the wire are very fine so the whole thing will be flexible. https://www.amazon.com/BNTECHGO-Silicone-Flexible-Stranded-Tinned/dp/B09X45RZCQ It's not super cheap, but after debugging two cases of thermistor wires broken inside a cable chain I decided to take the plunge and I'll never use the cheapo stranded stuff again.
Lastly, a good soldering iron is a good investment. I have one like this that I like: https://www.amazon.com/dp/B07Z3KCVCL
PS - and get a little tub of tip-tinner to refresh the tip of your soldering iron when it becomes hard to melt the solder on it. https://www.amazon.com/Thermaltronics-FBA_TMT-TC-2-Lead-Tinner-Container/dp/B00NS4J6BY
-
RE: G1 H4 with RRF 3.x
@droftarts - Ian, thanks for the clarification and additional info. I always learn something from this forum. Knowing that the endstops are ignored on all but H0 helps me understand more clearly how it works.
The more important thing I learned is that there can only be one end stop per motor and the design we are using does indeed have two NC endstop switches wired in series. We have recently been contemplating separating these to two inputs because in normal use, this motor is at rest with one of them triggered. In this situation, we can only know which end of travel we are at rest on by keeping track of it in sw - a risky proposition that a second input would eliminate. Now we know there will be additional macro work to do if we follow that path (re-define the endstop before making any moves). That'll be something for us to really look hard at.
-
RE: G1 H4 with RRF 3.x
@Phaedrux - I expected the G1 with the H4 parameter to follow the description I pasted in from the dictionary page above. Specifically:
-
Move until the endstop is reached, but do not ignore soft limits. I say this about the limits because the H1 and H2 parameters are explicit about ignoring soft limits and the H4 description omits this.
-
When the limit switch is reached, update the current position but do not change the axis limit.
In my use, I find the second bullet point is followed, but not the first - specifically, the soft limit is ignored.
My use case is with a Jubilee Remote Elastic Lock, a clever (but complicated) bit of design used for locking an E3d-type tool onto the printer carriage. Turning the motor in one direction finds a fixed limit switch, which is used to set the 0 position of the axis. Turning the motor in the other direction moves easily until there is resistance to turning, then a spring is stretched until a second limit switch is triggered. The spring ensures a certain amount of torque was applied. This all means that this second limit switch is not at a "fixed location" and so can't be used to reset the axis limit.
When I use G1 with the H4 parameter to lock a tool onto the carriage, I give it a move beyond any reasonable value, expecting the second limit switch will be triggered and stop motion without resetting the axis. This is working, and I can see that with a particular tool, the lock engages are a position of 110. As an experiment, I set the soft limit to 100 and reran the experiment. Based on the description of H4, I expected the axis to stop when it reached position 100, but it continued to (and stopped at) 110.
-
-
G1 H4 with RRF 3.x
I'm wondering if there might be a typo in the documentation for the H4 parameter on the G1 command (for RRF 3.2 and up) in the gcode dictionary.
I'm using this command on a U axis with endstops and it seems the axis limits are being ignored, as documented with the H1 and H2 parameters.
Heres what it says in the gcode dictionary:
G1 Xnnn Ynnn Znnn H4 Sense endstops while moving, update the current position at which the endstop switch triggers (supported in RRF 3.2 and later).
-
RE: Is there Object Model variable for "move outside soft limits"?
Quick follow up questions for @dc42
The OM move.limitAxes variable seems to indicates whether moves are allowed outside limits, but it doesn't indicate if any of the axes are currently outside their limits. I think this can only be understood if I do a G4 P0 (to wait for any moves to complete), then look at each axis, as you indicate.
Second question: can the extruder be an "axis outside limit"? I think not, only because there is no soft limit set by the user (in config.g) on this "axis". For example, if my extruder is set to absolute positioning and I retract some filament, can this cause RRF to believe I have an axis outside the limit and then throw the following warning: Error: G1: intermediate position outside machine limits? I think it will not, but I've been switching my extruder to relative positioning (M83) before making extruder moves in my tool change macros, then changing it back to absolute (M82).
-
RE: [3.5.0-rc2] Head Crashing into the print at the end of the job
You refer to end.g being empty. Did you mean stop.g? That is the file (in the sys directory) that gets called when a print is finished.
The behavior you describe sounds like the fw is ignoring the G91 command. This is a long-shot, but maybe there's an un-printable character after the G91, making it unrecognized by RRF and skipped.
-
RE: [Solved] What filament is loaded?
If you have multiple tools, you might also not have the extruders assign in order (example extruder 0 assigned to tool1). You might also have two extruders assigned to one tool. In these cases, you need to use look at the tools section of the Object model where you can find an array of objects in tools.extruders. For each tool, the array maps that tools extruders to the move.extruder number.
-
RE: Is there Object Model variable for "move outside soft limits"?
@dc42 - thanks for the pointer to move.limitAxes. This should help us a lot.
A little background on our work. We're developing our tfree.g, tpre.g and tpost.g macros fro tool changing. Our tools are all parked outside the soft-limit are of the machine. Our simplified approach for a tool change has been:
tfree.g -
- G53 move to a position right in front of the parking spot for the tool.
- allow movement outside soft limits
- G53 move the tool to the parking position and call the macro to release it
- G53 move to get back inside the soft limits
- don't allow movements outside soft limits
tpree.g
- G53 move to a position right in front of the new tool parking space
- allow movement outside soft limits
- G53 move the tool to the "grab" position and call the macro to lock it to the carriage
- G53 move back to get just free of the tool parking posts (but still outside the soft limits)
- don't allow movements outside soft limits
tpost.g
- allow movement outside soft limits
- heat the hot end
- purge some filament
- G53 move one (or more) times over a wiping thing
- G53 move to get back inside the soft limits
- don't allow movements outside soft limits
- memory slot 2 relative moves back to the original tool location
Our current theory for root cause is the macro that locks the new tool in place is leaving the U axis beyond it's soft limit which is causing the last moves in tpost to be blocked. When we try another tool change immediately after, the first move (to the spot in front of the parking space) in tfree gets blocked, but the subsequent move into the parking space is not. That lets the tool move into the wrong location, resulting in lots of noise, sometimes broken parts, and a quick run to the power switch.
-
RE: Is there Object Model variable for "move outside soft limits"?
@gloomyandy - Thanks for the idea. I won;t be back in front of the printer until next week, but I'll grab the precise message then and post it.
And I also had an idea that any single axis outside it's limit would restrict moves only on that single axis, but I can see how moving on another axis could get you into trouble is one axis is out of bounds. I also did not expect that those moves would just be skipped with a warning, allowing future moves (that are preceded with a G53) to be executed. It's also possible I'm not quite a root cause of my bug yet and this axis out of limit thing is a red herring.
-
Is there Object Model variable for "move outside soft limits"?
We're working on tool-changing macros for our printer and are using a U-axis to actuate the Jubilee inspired tool lock and unlock mechanism. In the course of developing and debugging our macros, we've had a few instances where the u axis moves beyond it's soft limits while we have those limits disabled via M564 S0. All OK, so far. When we move back within the X,Y,Z soft limits and re-establish the soft limits with M564 S1, there have been times when the U axis is not back within it's soft limits.
We clearly have a bug in our U axis design, but the behavior when we're in this state (U axis outside limits AND moves outside limits not allowed), is bothersome. Moves that are only X and Y are ignored (and a warning message flashes). We've had a few crashes in the docking area due to this.
So (finally) my question - is there a variable in the Object model that indicates that an axis is currently outside it's soft limit? My thinking is that just prior to running our M564 S1 (return to soft limits), we can see if any axes are outside and take some action - like halting operation.
Thanks. and happy spring to anyone living in a latitude where that's an important milestone.
-
RE: re-naming tool change macros
Thanks for the feedback and the pointer to the doc page.
@deckingman - I like the idea of common docking and undocking macros, but at the present time, we're keeping all the commands in each macro to make it easier for us to design and debug.
@infiniteloop - The page you referred us to is a big help (I was using this: https://docs.duet3d.com/en/User_manual/Tuning/Macros and this: https://docs.duet3d.com/User_manual/Reference/Gcodes#t-select-tool and the G60 command documentation). I'm a big fan of not guessing about what the fw is doing, but sometimes we've found that not every step gets documented, so I thought I'd query the collected wisdom. (For example, the page you referred me to has clear steps identified, but omits the step where the fw saves the current tool position into "slot 2" before calling tfree. This is documented elsewhere, but no on this page.) Not complaining, just trying to be thorough.
-
re-naming tool change macros
We're working on adding tool changing to our printer and we're not liking the macro names tpreN, tfreeN, and tpostN. This is NOT a request for them to be renamed. What we're thinking is that we would add some redirection to those macros using M98 commands.
-
tfreeN would call a macro we'd name tool_N_park
-
tpreN would call a macro we'd name tool_N_unpark
-
tpostN would call a macro we'd name tool_N_after_unpark
These names would be more meaningful to us and would collect all the tool-change macros for a single tool next to each other in the sys directory.
My question is whether there is any behind-the-scenes stuff that happens in the firmware that we'd break with this strategy. The only thing I can think of is the automatic storing of the tool position coordinates in "slot 2" when a T<N> command is issued, I from my understand of how M98 works, this should not get broken.
My worry is that if the M98 command is the last statement in one of the tool change macros (tfreeN, for example), will the fw believe tfreeN is completed when the M98 is called, or when the M98 completes?
-
-
RE: Which printed materials would self extinguish?
@DocTrucker - Adding to DC42's comment. I used to design enclosures for personal computers and servers (and back in the day - "mini computers" the size of a washing machine) and the relevant UL safety standard is UL94. There are several ratings within UL94:
In our designs, we always specified plastics that met the UL94 V-0 criteria. I did a quick search and see a lot of filaments with the 94V-0 rating. They are all labeled flame-retardant. ANd they can be pricey. I saw a roll of flame retardant PLA on amazon with a 94V-0 rating that was $68. Yikes
The plastic composition is adjusted to meet different ratings, usually by adding fillers, sometimes just chemically. I'd expect that the printing parameters might need to be tweaked to optimize with these materials.
-
RE: automatic start a marco when the printer is on?
I have a macro that runs when I start the printer to do some startup tasks - heat the bed, home the printer, level the bed, generate the mesh. To deal with the issue of having the printer start moving on its own, I post a blocking M291 message to the user asking if they want to start the process. The need to give the OK.
-
RE: How to get started with daemon.g
My top tips for writing code daemon.g are:
-
Don't forget - It's just a macro. Anything you can write in any other macro can be written and run in daemon.g.
-
Don't forget - It runs every 10 seconds. Anything you put in will run again and again unless you make it stop.
Often times, you'll want to run something just one time, when something happens. You can use daemon.g to watch for that thing to happen. This is in the form of an IF statement in daemon.g, followed by the thing you want to do. (I have one that watches for the network to connect, then I display the IP address on PanelDue). Now I need a way to stop it from happening again. I nest the IF statement above in another if statement that looks at a global variable called something line global.not_run_yet. If not_run_yet is TRUE, then the code proceeds to check if the network is connected. And if it is true and the network is connected, then after I print my message, I set the value of global.not_run_yet to FALSE. Next time Daemon.g runs, this will cause it to skip the print statement. To make this work, you need to create the global variable somewhere other than daemon.g . It might be in config.g or another macro called by config.g.
In my case, I also wanted to give the system some time to get that network connected, so I created a global variable that is used as a counter. If daemon.g gets past the IF network_not connected command, I increment the counter. If the counter gets to 5 (meaning daemon.g has run this code 5 times, or 40-50 seconds have passed), I decide to stop trying and set"network_not_connected" to False anyway.
-