How to get DWC to Display what line of Gcode it is on?

AndyE3D

@Tinman hopefully I can help getting to the cause of the issue. Please can you do 2 things for me:

Provide you system configuration files & macros so I can try to recreate the issue
- If you don't want to share all the config files then please share the ManualToolChange.g as it is used in the .gc files you uploaded.
Try removing the M0 from the end of the files you have uploaded and run them again. Let me know if you still get the same freezing issue

Tinman

@AndyE3D Really appreciate your time on this. I have attached the manual toolchange file. My macros are admittedly not the prettiest code since they are a work in progress. We will develop final macros when the concepts are proven.

ManualToolChange.g

Tinman

@AndyE3D That macro also calls a macro that determines the tool length:

ToolZProbe.g

Tinman

@AndyE3D And before the job is run a macro is run to set the WCS to the centre top of the workpiece:

Centre Workpiece.g

Tinman

@AndyE3D So the order of macros is:

Centre Workpiece.g is run so that the WCS knows where the top centre of the workpiece is.
The Tall Axle Insert Whole Job.gc file is run and before milling starts and with each tool change it calls:
a)ManualToolChange.g which then calls
i)ToolZProbe.g

There are two sensors used.
1. a sexbolt sensor which is used to determine xyz probe length as well as tool length
2. an xyz probe mounted in the spindle for the duration of the Centre Workpiece.g process

There is also a global variable defined in config.g which is used to exchange z offset information between the Centre Workpiece.g macro and the ToolZProbe.g macro. You can see it in this file

config.g

AndyE3D

@Tinman I've had a look through the files and nothing is immediately obvious that would cause the issue. Do you have any triggers, a daemon.g, or any other code that may be running on the Duet/sending commands to the Duet?

Also were you able to try the print file without the M0 command at the end?

Another thing I would like you to try is to add M400 to the start of each of the macros. If it is an issue with the second file reader, this should cause them to resynchronise.

AndyE3D

@Tinman I have been able to reproduce similar symptons to what you have described using a much shorter gcode file. The only differences appear to be that this will cause the Duet to hang consistently at the same line in the file compared to the position changing, and the duet becomes unresponsive to gcode (except estop).

@dc42
https://github.com/Duet3D/RepRapFirmware/issues/859

AndyEveritt created this issue in Duet3D/RepRapFirmware

closed [Bug]: Duet becomes unresponsive when printing #859

Tinman

@AndyE3D Thanks for looking at everything. I did try with M0 removed and had the same trouble. I haven't used any triggers or daemon.g or anything fancy. I will try inserting an M400 in the macros.

In my most recent attempt at a multi toolchange file I removed the M0. Early in the job the z axis decided it wanted to dive at top speed into the workpiece. It was alarming.

As before when I take exactly the same job and break it up into individual jobs everything runs fine.

Tinman

@AndyE3D OK, I think I found out the cause of the problem- at least I have a theory... In my macro I had the z probe macro and xy probe macro making three samples and then averaging them to come up with the final WCS figures. The averaged figures have more decimal places and this seems to mess with the ability of the board to process a longer multi-machining-process file. When I remove the averaging procedures from the probing macros everything seems to run fine.

dc42

@Tinman I can't see any reason why additional decimal places should cause a problem. Please share those macros so that we can do some testing.