That looks like a modified version of an old calibration test for Marlins linear advance. It draws a series of lines back and forth with varying amounts of pressure advance and you're supposed to find the line that gives the most even start and stop.
I haven't had much luck with it, as all the lines look basically the same, but I don't use much PA to begin with on a direct drive. For a bowden system it may be more apparent. There's also the issue that it's only a single first layer so it's likely to be squished down a bit which isn't a great real world test.
I think a better way to test would be to print a slightly more complex model with some height and varying the PA value every 10 layers or so, then you can get a better idea of the changes as the model progresses. You can either insert the PA command into the gcode file, or issue it manually from the gcode console.
If you have a PAnelDue, something like this can be very handy for live tuning. https://forum.duet3d.com/topic/6181/tuning-macros-menus-accel-jerk-retraction-pressure-advance
There's also this script for trying to find a good PA value.
@bernie-mix said in Attempting to extrude with no tool selected - During Print:
I have grounded my printer frame with the ground of 220V power outlet. Should I disconnect this grounding and instead connect the frame to the negative of the power supply output? Or must this connection persist and additionally the negative output connect to the frame?
Unless you use the USB connection regularly, it's best to connect the frame to mains ground and also connect the negative PSU output to mains ground. But if/when you use the USB connection, see https://duet3d.dozuki.com/Wiki/USB_ground_loops.
When R is set to 2 should it stop as soon as it detects a crash or does it finish the current move? After more testing I believe that it detects the crash the same regardless of the R value but when R is 2 the printer keeps moving prompting me to shut off the printer to prevent damage. Since the gcode I have been using to test crash detection tells the printer to move far past the location of the crash, I need it to stop as soon as the crash is detected.
I was able to make crash detection work as I intended by using R3 to rehome and using M291 to inform the web interface of the crash and pause the printer until I am able to monitor the restart of the print.
@dc42 I am running a chimera and I think my main concern is having the x axis the closest. I set my nozzle heights after I get dialed in. Its been working really good. It also seems like if I had a single nozzle it would be better if I could get it super close in 1 axes and close in the other. Rather then really close in all axes.
Hi thanks, for the info but as I havent meshed the bed yet I cant ignore it and using G30 without the switch, the head crashes in to the bed, I have no desire currently to use IR probe. How can I disable it or have the firmware ignore it?
As above recently updated and now having issues.
@dc42 said in Piezo Settings:
Can you confirm that you have connected the piezo to the Z probe connector on the Duet, not the Z endstop input?
OMG, Yes I was installing my X and Y endstops at same time and I plugged the piezo into the Z stop instead of the Z probe port, thank you, it's working now
If I was to do it how you suggested making 0,0 the bed center, would I then change my x and y minimum and maximum setting in my config?
Change from this
M208 X-9 Y0 Z0 S1 ; Set axis minima
M208 X300 Y300 Z250 S0 ; Set axis maxima
M208 X-159 y-150 Z0 S1
M208 X150 Y150 Z 250
@3dware, did you solve this problem? If not, please provide more details of your machine and the config.g file. Does it have 4 separate nozzles, each with one heater and one extruder, or a single nozzle with one heater and four extruders feeding it? Or something else?
Okey I got it: its the material of the bed! I dont know why and I dont really care. I took a piece of a 400x400 mm woodplate and started the whole AutobedCompensation process. Now Z0 is truely Z0 everywhere. Crazy accurate. I also moved the probe closer to the nozzle. Now the offset is only 15mm in the y-axis.
Lessons learned: the probe is great(when you use the right bed material)
Regarding the Z endstop switch, you can define the Z homing sequence (in homez.g and homeall.g) to move the print head to a suitable XY location before it executes the Z homing move. But perhaps it would be safer to adjust the position of the switch so that it triggers a little higher up, if that's possible. Alternatively, if the machine has a Z probe, you can use that to home Z instead of using the homing switch.
In your homing files, you can have the head move to a safe position after homing X and Y to avoid crashing into the metalwork.
See https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter#Section_Homing_files for infoirmation about the homing files.
There are two sets of coordinates: user coordinates and machine coordinates. Currently, DWC displays only the user coordinates, which are the coordinates that the GCode file you are printing commands. DWC has access to the machine coordinates as well, so future version may give you the option of displaying them. Meanwhile, if you send M290 then it will report the current babystepping.
Yeah, but you don't have to home to the origin, you can home to any combination of Xmin/Xmax/Ymin/Ymax/Zmin/Zmax.
It is worth considering Zmin/Zmax and weather or not homing while there is a print on the bed can be an issue.
I interviewed for a job at a manufacturer of construction equipment. They had a construction planning tool that was a mix of 2D and 3D graphics programming. I was told the program was written in VB.NET and they wanted a re-write in C#. It was actually VB6 and they wanted someone to maintain the pile of crap. Typical bait and switch job.
There was a file named Global.bas that contained over 600 global variables. Pi was defined 3 times in the code, with 3 different values, in 3 different files. Pi varied somewhere out around 8 or 9 decimal places. 3.14 was precise enough for any calculations. Looking at the code, you could see the original developer didn't know much about programming. In early code, he didn't use parameters in methods. Nothing was passed in. Values were stored in the globals. Before calling a method, the global data was stored in local copies, the method would be called and act on the global variables, sometimes modifying them. When the method returned, the local copies would reset the global values. Later code showed where he learned about parameters and started using them. Cartoon HD
The graphical portions had text config files to hold measurements of the construction equipment. The measurements were transformed into graphical objects using variables for vertices. The first vertex was named a. The next b and so. These were very complex drawings. Way more than 26 vertices, so the 27th vertex was named aa. There were variables names like:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabc Vidmate APK
As it turned out, I only fixed one bug. There was an instance where two objects overlapped on the screen. I found a line of code commented out. I removed the comment and it fixed the overlap. I'm sure I returned some other bug, but there was no bug tracking or task linked in source control to know why the code was removed. 9Apps
Later the company added a new piece of equipment that was larger in scale than anything they had ever built. They wanted it added to the tool. Another developer and I worked for about 3 months on the config file and coding it into the program. The blueprints we were provided had inconsistent measurements for key parts of the equipment. We started asking the mechanical engineers for clarification and were told not to contact them again under any circumstances. We finished the coding and requested a demo. The mechanical engineers refused a demo. It turns out, they wanted to replace the in-house tool with a third-party tool and thought we would fail at rendering the new equipment and would use that to justify buying the new tool. People who did see it said it was the most accurate model in the program. The new model never went into production and the third-party tool was bought as a replacement.
None of the above is the weirdest part of this story. The original developer made the wise choice to leave programming. He became a contestant on a reality show and won. He is now an "actor" in Hollywood. Don't ask which show, I won't dox him.
Your config.g is wrong. You have:
M305 P0 ; Configure PT1000 for heater 0
M305 P1 ; Configure PT1000 for heater 1
A cursory review of the documentation shows you need more parameters than that.