Error: bad Command XXX W/RRF 3.2 and leveling issue
-
@3DPrintingWorld said in Error: bad Command XXX W/RRF 3.2 and leveling issue:
Not sure what you mean "current files",
In case you've made any changes since posting.
-
@Phaedrux I've made changes but I reverted back to the original after testing.
-
The only thing I can think of to cause the leveling to be oposite of expected is if the order of the motors doesn't match the order of the points defined.
You must use the M671 command to define the X and Y coordinates of the leadscrews. The M671 command must come after the M584 command and must specify the same number of X and Y coordinates as the number of motors assigned to the Z axis in the M584 command; and these coordinates must be in the same order as the driver numbers of the associated motors in the M584 command. The M671 command must also come after any M667 or M669 command.
https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors
I can't see your printer so I don't know which motor is at which point, but that's the first thing I would double check.
-
@Phaedrux I don't think the leveling is opposite as expected. It adjusts to the same plane every time, its just off level with the left back corner low and front right corner height. I swapped the motor drivers because it should make the leveling different, but the leveling stayed exactly the same. I swapped right and left motors and left and back motors. Therefore I dont see why it matters if my motors are assigned correctly because no matter their assignment the bed is leveled to the same position.
Circling back to if the motors are assigned and wired correctly, there are two others builders that used my config.g and wiring as a basis but are not having this issue. Plus the bed was leveling properly for six months and I have not changed the wiring or the motor assignment.
You can find the wiring diagram here:
https://github.com/3dprintingworld/MULDEX/blob/master/Images/MULDEX WIRING DIAGRAM.png -
Is there a skew in the frame? Tilt on the print head?
-
@Phaedrux
I don't see how the frame could be out of square, the extrusions are machined square and butt connected together so its not possible for it to no be square.Also, the axis would have to be skewed so far to result in a .4mm vertical variance in level of the bed.
-
Here is what I verified mechanically:
- I tried a backup BL touch
- Tried running the cable for the BL touch separately incase there was interference with the heater cable.
- I rebuilt the extruder carriage twice to make sure there was nothing wrong with the assembly.
- Checked the set screws on pulleys.
- Checked belt tension.
- Loosed up the cable loom and supported it as the printer homed to verify the loom was not pulling on the carriage resulting bad readings from the BL touch.
-
How can I run this trigger test macro that probes the three places used to home and it says the deviation is less than .01mm but in reality its .4mm? I can run the macro a bunch of times and it will return a .002 to .009mm deviation. Its repeating very accurately, but it seems as the printer thinks its level but its not.
T0 G28 G90 M558 F60 ; Slow probing speed G30 P0 X200 Y285 Z-99999 ; Probe Middle G30 P1 X15 Y15 Z-99999 ; Probe Left G30 P2 X324 Y15 Z-99999 S-1 ; Probe Righ
-
@3DPrintingWorld you my have checked this, but do you have your heightmap loaded when running bed.g? If mesh compensation is active, it will cause something similar where the bed looks tilted, but it adjusts it up and down so the probed height doesn't show thr tilt.
I always start all my homing and bed.g files with a G29 S-2 to make sure I don't have a heightmap loaded (/mesh compensation active) -
@3DPrintingWorld said in Error: bad Command XXX W/RRF 3.2 and leveling issue:
How can I run this trigger test macro that probes the three places used to home and it says the deviation is less than .01mm but in reality its .4mm? I can run the macro a bunch of times and it will return a .002 to .009mm deviation. Its repeating very accurately, but it seems as the printer thinks its level but its not.
My guess is that the print heat is tilting a little depending on the direction in which it last moved. This will cause the relative heights of the nozzle and the BLTouch to change. Please post photos of the print carriage assembly.
-
HI,
I have built the same design, just measured the tilt in the X linear cartridge. It is 0.07mm in Z direction on the nozzle and is caused by the tolerance linear rail to block LDO MGN9 . So there is a few hundreds luft between the block and rail and due to the center of the nozzle( and BL touch) being about 20-25 mm cantilever, the resulting is 0.07 measured with a dial indicator on the tip of the nozzle. SO no way this can give 0.4 mm difference. The U axis caridge has a similar wobble.
I think We may need a better linear rail and block for the X axis. What I see is that I do G32 it makes the initial correction, then G32 with -1 and it reports deviation of about 0.1to 0.15 mm , then I do G32 S3 again and then G32 -1 and it reports 0.002 to 0.01 deviation, from there every G32 reports under 0.01 -
@engikeneer Thanks for the tip but I do have the mesh turned off.
-
@3DPrintingWorld Yep , because on startup it is turned off
-
@dc42 said in Error: bad Command XXX W/RRF 3.2 and leveling issue:
My guess is that the print heat is tilting a little depending on the direction in which it last moved.
I wanted to verify it was not being caused by anything mechanical before bring up this issue so I completely disassembled it and worked on it for a couple weeks before writing this post to make sure nothing was loose or broken. I even tried loosening the wire loom and holding it by hand to insure it was not pulling on the carriage.
I think a wider or a second bearing would help to keep the carriage from tilting but like @martin7404 has said, I don't think it there is enough play in the carriage to have this much effect.
If the issue is slop in the head, I don't see how it would repeat to the same level each time. Also, you would not think the trigger tests would repeat within .01mm when moved around the bed. It also does not explain 6 months of good leveling. I would also think if slop was the issue prints would look very inconstant, which is not the case.
To test your theory since the BL touch is on a cantilever, I could weight down the end of the carriage and home it really slow. A couple pounds on the same side of the bearing as the BL touch will remove any chance of the head tilting back. This should debunk if tilt is the issue or not.
I'm not saying its not mechanical but I am unable to see it.
-
@martin7404 I manually sent a G29 S-2.
if you reset power, I thought it looked like it retained the last map used?
-
@martin7404 I considered a second bearing as a backup if a single bearing did not work out,
but it did. I wanted to keep it as light as posable. Its the same bearing as the tool changer uses with the same length cantilever to the nozzle but the Muldex carriage is much lighter so it should be no problem. Their probe is much closer though. -
@dc42 said in Error: bad Command XXX W/RRF 3.2 and leveling issue:
My guess is that the print heat is tilting a little
To test your theory that the head is tilting , I put a 700g steel bar as shown in the picture to cause the bearing to tip forward and to remove any potential bearing slop. But, the level is still the same. Back right corner low, front left corner high.
-
In this case I might backup my config and start with a fresh basic set for testing.
-
One other error to put on the list from updating to 3.2. About once in every twenty to fifty startups I get this error, it causes the machine crash into the Y endstops. The error takes place as its homing Y, way before it ever gets to the G30. Never seen this error on 3.1.1.
I still get "bad error" command every time I reset and T2 fan still comes on every other time power is reset.
-
@Phaedrux said in Error: bad Command XXX W/RRF 3.2 and leveling issue:
In this case I might backup my config and start with a fresh basic set for testing.
There have been a couple instances where I waisted a lot of time trying to figure a issue out thinking it was user error because I am new to RRF only to find that it was a bug in RRF. Are you sure the issue has to be on my end?