Failed print after a few layers, Error: G0/G1: target position

T3P3Tony

@3DPotter then, as @dc42 said, it's probably the slicer sending a G1 to move between two positions that is not a possible move with the scara arm.

3DPotter

Is it possible to disable a safety to allow it to attempt this movement?

droftarts

I can't see anything obviously wrong in the gcode you sent (I saw from the video you were printing the "9-12b dd22 Not Working.gcode" file); no wild moves or strange commands dropped in. Could it be that the file has corrupted on uploaded to the Duet, and has created a move that it can't complete? You can edit the gcode file in the Duet Web Console. Open the file on the SD card through the DWC, copy and paste that into a new text document, and post that.

In the meantime, you could try a new SD card, or uploading the file again.

Ian

T3P3Tony

@3DPotter can you identify the line and try that movement... I have a feeling the slicer may be asking the arm to make a movement it can't do, or the current configuration means it can't do.

I don't believe you can disable it because this is a physical limit of the motion system (as configured).

3DPotter

Is there a command to monitor CPU usage? Perhaps it is being overloaded?

This File fails within the first few second of the print. pw 9-13 3 test failed.gcode

Tried new SD card, flashed firmware, tried all versions within the last year. Tried new boards. This is really confusing as this came on suddenly. We have been printing fine for a year. And it is occurring on 3 different machines. We have tried using old Simplify 3D profiles. Tried using old configuration files. Inspected the Gcode manually and don't see anything out of the ordinary. Inspected the board and cables, don't see anything out of the ordinary

T3P3Tony

@3DPotter I am non my phone right now so hard to open the gcode file.

In the same file as the video you posted earlier can you post the successful block of gcode form the layer that works., and then the block of gcode form the layer that fails

3DPotter

After going though many different firmware versions, I figured out how some of them affect the machine.

I will make a new post concerning them, as there will be full documentation with videos and files showing which firmware version affects the machine in what way. Such as what can cause it to crash or not, and what is too safe making it not move because it thinks it will crash but it was not going too. This will take a bit of time on my part to finish.

TL;DR- Newest versions have too many safeguards causing the machine to stop prints. Using and older version (2.03RC1) that works for now.

dc42

@3DPotter, is it possible that the print requires a movement that crosses the inaccessible zone close to the distal joint? I remember that was a problem earlier.

Dugee

I am very interested in this as I keep getting the same message - the only way I have been able to bypass this so far has been to increase the final Z- movement under G91 conditions to -20. I'm doing calibration and I seem to get it after the first autocalibration, meaning that I cant perform a 2nd to improve the result.

; homedelta.g
; called to home all towers on a delta printer
;
; generated by RepRapFirmware Configuration Tool v2.0.3 on Sat Sep 14 2019 00:35:56 GMT+0100 (British Summer Time)
G91 ; relative positioning

G1 S1 X140 Y130 Z140 F1800 ; move all towers to the high end stopping at the endstops (first pass)
G1 X-5 Y-5 Z-5 F1800 S2 ; go down a few mm
G1 S1 X10 Y10 Z10 F360 ; move all towers up once more (second pass)
G1 Z-20 F6000 ; move down a few mm so that the nozzle can be centred
G90 ; absolute positioning
G1 X0 Y0 F6000 ; move X+Y to the centre

Dugee

Turns out I had massive calibration errors caused by a stuck idler wheel. Problem solved

3DPotter

@dc42
It was an issue a long time ago, but was fixed with an unknown firmware update. Some path movements were extremely odd with older versions, things like disregarding motor speed in order to maintain head speed at all costs. Or arm movement take the longest way around the machine in order to reach a position.

The major movement problems were corrected in update 2.03RC1, but not all of them. Also, this update did not obey minimum travel distance correctly, M208 S1, and did not always take the most efficient paths.

With update 2.04RC1, it seemed like everything was fixed for us and things went great. All pathing was taking the most efficient routes (better than before), all limits were being followed, and no machine crashing. But it must have slipped under us, as when we started to print more complex g-code files we would get that Error: G0/G1: target position not reachable from current position. We do not receive this error on version 2.03RC1, and the print runs fine.

Currently we are running on 2.03RC1, but as I mentioned some safety feature are not working and it is easier to crash the machine into itself.

We want the minimum limit M208 S1 to be obeyed as well as have the best pathing. If you would like I can go through the updates to see what problems occur on them and provide documentation/files with videos of how the machine is operating.