@dotorg said in First Layer Rippling: What to try next?:

@fcwilt For what its worth, the default files created by RepRapFormware Configuration Tool do not configure it that way. They have M561, G29 in bed.g, and do not have a mesh.g.

Where did you see that its should be the other way? Given the RRF Configuration Tool is the "official" way to set up the configuration, what you're saying seems to not be in alignment with the recommendations.

The configuration tool is out of date and generates code with numerous shortcomings. That is one reason I never use it. I encourage new users to learn how to configure their printer without it, the knowledge they gain will serve them well.

Consider the following screen shot of the DWC from firmware v3.3.0:

DWC Pull-down Menu.png

Notice the wording and the associated commands. Also if you read the docs for G29 you will see mention of the file mesh.g.

The firmware supports both ManualBed Leveling (MBL) and Automatic Bed Leveling (ABL). MBL is generally not something that is done for every print but some folks generate a new height map for every print.

On the other hand I generate the height map once and use it for all subsequent prints. But I perform ABL for every print.

Thus it makes sense to me to use bed.g for leveling operations and mesh.g for height map creation operations.

If you always perform them together you simply execute G32 then G29.

If, like me, you perform them separately you execute G32 or G29 as needed.

Thus my belief there is no reason to not follow the convention. And it keeps your code in sync with the "expectations" of the DWC.

Frederick

@droftarts @dc42

I have connected my flow sensor like that and show always 0

ef8b453a-b80c-4629-ba8d-8e526a81b2a0-image.png

1 GND commom for all voltages
2 5V external power supply
3 signal connected duex.gp4

; Water colling PUMP ############################################################################################################# M950 F2 C"Fan0+^duex.gp4" Q25000 ; fan 2 is a 4-wire PWM fan so invert it, use high PWM frequency

@infiniteloop Agreed! Also I didn't intend to take over the thread, I just wanted to make sure that the OP didn't get the wrong (IMHO) idea about PETG.
Anyway, we are all good .... at least from my end 🙂

@fcwilt awesome thanks i will check

So i couldn't recreate the issue with another cable..Frustrating when trying to show shielding fixed the issue, but I'm still confident that was what helped...mostly. Still, I had another test print showing what i have moved away from when EMF was an issue regardless of the solution ( cable pathing or shielding). I adjusted contrast so the visibility was clear even if the colors are looking a little artificial. The surface issue was apparent in any print with the outer layer lower than 60mm/s.
20220423_200324.jpg

@the-chairman, copy and pasting from your config.g file above
M203 X6000.00 Y6000.00 Z180.00 E1200.00 ; set maximum speeds (mm/min)
That is the maximum that the system allows but not necessarily the fastest it can go. That becomes a trial and error thing where you increase the speed until you loose steps and then you back off on the speed until you are happy with te safety margin.

@gnydick NM, brain fart

@obiwan2print said in Max Bed Level Compensation Z probe not triggered G32:

My current config files are different it turns out. How do I display them so I can paste them here? Also should I take out wifi info? From my current config.g file I have these lines:

M558 P9 C"^zprobe.in" H5 R1 F50 T6000 A5 S0.02 ; RRF3 BLTouch connected to Z probe IN pin
M950 S0 C"duex.pwm1" ; RRF3 Define BLTouch Servo (S0) on duet pwm1
G31 X-4 Y-42 Z2.65 P25 ; Customize your offsets appropriately - do a paper test, and put the probed value in the Z value here

Well that looks better.

If that is not working then I would check the wiring from the probe - as I recall it was a black and white pair of wires.

Frederick

@moth4017 what I think is happening is that after homing X, the 'stalled' flag is still set in the driver that stalled first. In a CoreXY machine both X and Y motors are used for both X and Y moves, so that 'stalled' flag will cause the machine to think that Y is homed if you then try to home Y.

The solution is: after homing X, move the head back in X a small amount to clear the stalled flag. Similarly when homing Y.

@equipment66 use M226 instead of M1.

@phaedrux I really appreciate your help with this... Thank you!

I haven't received the heating too slowly error since I tried tuning again. I added a basic PID value before I ran it. I think that made the difference.

When I say it's heating really slowly, apart from the error, I mean complared to the same printer with the original main board. It's the stock heater bed.

I'm running a tuning cycle right now. I'm including the screen cap of the process during Phase 3 Phase 3.png at 19 mins in.

@tricep-terry that's good news, thanks for telling!

@ibats Have a look here to quickly compare the options https://docs.duet3d.com/en/Duet3D_hardware/Hardware_overview

@dc42 said in 1HCL closed loop steppers on CoreXY:

M350 X16 Y16 I0

Hi David, I gave it a go and it was much worse without the interpolation. On a side note, it doesn't seem you can change that parameter on the fly as I was getting this error and the printer would unhome x and y, but the z was fine

4/20/2022, 6:50:19 AM M350 X16 Y16 I1 Cancelled printing file 0:/gcodes/Voron_Design_Cube_v7.gcode, print time was 0h 3m Error: G0/G1: insufficient axes homed 4/20/2022, 6:46:38 AM M32 "0:/gcodes/Voron_Design_Cube_v7.gcode" File 0:/gcodes/Voron_Design_Cube_v7.gcode selected for printing 4/20/2022, 6:45:32 AM M350 X16 Y16 I0 Cancelled printing file 0:/gcodes/Voron_Design_Cube_v7.gcode, print time was 0h 1m Error: G0/G1: insufficient axes homed 4/20/2022, 6:44:00 AM M32 "0:/gcodes/Voron_Design_Cube_v7.gcode" File 0:/gcodes/Voron_Design_Cube_v7.gcode selected for printing

Regards,
Sam

Hi all - I took bits of all your responses and ended up making a tuning macro that brings the chamber temperature to my normal printing temperature first and then runs the autotune. When actually printing, I've adjusted my gcode to bring the chamber to temperature first (in serial) before heating the bed, rather than in parallel as I did previously. Overall print time has gone up a bit, but a single heatup in the morning and then leaving it like that all day isn't too bad.

Thank you!

@dc42 I am happy too, thank you! I had been bouncing my head off a wall and digging through the forums looking for so guidance before I posted. Then after I said let's give this a shot and dumb luck won the day. I was only using mesh as a tool to see what my delta calibration was effecting.

M703 ; execute loaded filament's config.g

It looks like you're using filament specific configs. Are you changing anything relevant there?

Do you have anything relevant here? M98 P"0:/sys/primeLine.g" ; execute primeline macro

If you write a short gcode, you can test to see if this is a dead-band issue in the servo. Try starting at zero, moving to 95, then 100, for example. Then, go back to zero and move directly to 100. See if you end up in the same place. You may have to adjust the number to see the dead-band.

Long and short moves on a servo can end up at slightly different places, unless the dead-band is set to zero, in which case the servo tends to vibrate when it is supposed to be holding.

Thanks for all the feedback, everyone.

I don't think volumetric scaling would compensate for part shrinkage because it would adjust the amount of filament extruded but not the location ofthat filament. It also sounds tricky and is also something done in the slicer and I'm trying to keep the slicing simple.

In the end, I used the M579 command and it's working perfectly as I expected because I'm scaling both X and Y by the same amount. If I was trying different scaling on each axis, my CoreXY would scale the print in undesired ways.

Cool, @deckingman, thank you. The 6000 was legacy from the RRF config tool, so I'm not even sure why it's there.

I'm on a steep learning curve, for sure 😨