On the beta firmware the macro tab is still present in the left menu. I have removed it from the persistent top dashboard, but you can still have the macro page and dashboard open at the same time, as the dashboard is persistent on every page. The touch probe issue will be fixed in 1.07
Hi Ryan, Yesterday with Beta 3 1.07 I was running a program that went into over-travel alert about 90% of the way through cutting the part, silly me, upon reflection I should have checked better . Anyway it led me to think that it would be better to know about over-travel BEFORE running the program. So I experimented with the SIMULATE FILE option and found that this reports the over-travel - great stuff. I'm not sure if this method is new to the V2 DWC that you have forked, but anyway it's useful. However there is a problem in that the Work Coordinates are invalid after the alert (probably at the position of the failure in the file, but in Simulation the machine shouldn't have moved**); it would be best to set the correct work coordinates or maybe force the user to ReHome after the over-travel alert. **Another problem with this alert is that there is a small X movement (<10mm) when the failure occurs, this is worrying because maybe the movement depends on buffering in the program (I guess that this is a Duet fault)?? Simulate File sets the correct Work Coordinates if it completes successfully, even if the end position in the program is different to the initial start position. Of course Simulate File with ToolPath Graphics would be nice for future, like UGS, but with over-travel, cycle time etc. Geoff
Thanks for your message, the simulate button has always been there. I guess to bring the error up before cutting, i just need to change the run G-Code command to simulate beforehand. With the Work Coordinates being incorrect, is this just when actually running the file, or with simulate as well? Ryan
If simulate fails (going outside machine limits) then workplace co-ordinates are screwed up - have to re-home to reset them. Alex.
Work Coordinates are wrong when the simulate fails, I'm not sure whether they were wrong when running the file, I was so dissapointed in myself that I Homed when it stopped. The small movement in the Simulate was worrying however. Running the simulate automatically prior to the Run is a good idea, but it may be a bit slow for very large programs (I'll test that). Not sure how Simulate works but looks like it runs through most of the Duet processing without motion. Geoff
The new DWC gets from me so far, but I need to investigate one peculiarity - tried to "air - cut" a job (in the middle of the bed) and got an "out of machine limits" error - after which WCS was haywire and had to re-home. Undoubtedly down to me, but haven't been able to duplicate it yet. I guess that answers the second part of @Ryan Lock's question. Alex.
Hi Ryan, I've tested a largish file (12Mb) on Simulate File and it takes over 15minutes, so I think it should remain optional. I don't know what the Duet does for Simulate but it's too much just to check over-travel, a pc based over-travel checking program incorporating toolpath graphics might be the way to go in the future, but that's not for today. So far as I can see over-travel in a running program is ok, in that I can Goto Work Zero after the alert and it returns the Machine to the same position as where it started (only from the coordinate display but it looks right). I need to prove that sometime because I worry about the Duet buffering! Geoff
Hi @GeoffH, I still haven't managed to replicate whatever error (on my part) caused the alarm when I was running a job, but it definitely screwed up wcs. I'm pretty certain I homed, jogged to centre of bed, set wcs0, ran job - I may have not lowered Z from home position which would have caused problems if it tried to move to Z safe height - will try that next time I wind up the machine. Alex. PS - I have switched off the dark scheme in appearance - not sure I really like either colour scheme.
Hi Ryan and Alex, I have had some instances where I would say that Setting Work Zero has not worked correctly although the Work Position is displayed as 0,0,0, it seems to me that it has not changed. Previous versions to 1.07 used "Set Work Coordinates.g" which was G10 P2 L20 X0 Y0 Z0 G55 M500 Does the js button now do? G10 L20 X0 Y0 Z0 M500 The problem is intermittent, anyway, I'll try tomorrow to duplicate the problem, maybe this is what you have experienced Alex? Geoff
Intermittent sounds ominous, unless we can work out what's causing it and stop doing that. Like you I will investigate this further, but maybe not until Saturday. This is one reason why I like things to be in editable files - you can look at them to see what they are trying to do. Alex.
There are files in macros/workplace settings (may have mis-remembered folder name while climbing stairs from cellar to attic) which I believe may be linked to the GUI buttons. Set workplace zero says; G10 P2 L20 X0 Y0 Z0 G55 M500 and they can be edited. P2 and G55 would be wrong if that's the case. Alex.
The js buttons run this: G10 P${move.currentWorkplace} L20 X0 Y0 Z0 M500 ${move.currentWorkplace} is the current work coordinate selected in the drop down list. I will look into your issue above some more. Ryan
Hi, I actually think i may not what is causing the issue. I think it could be due to work system being changed outside the selection drop down. Will investigate. The G10 command i posted above, actually doesn't even need the P command. Without it, it applys to the current system. Best Regards Ryan Lock
Hi Ryan, Thanks for that, maybe it's possible that ${move.currentWorkplace} is over-written sometimes. Did you test Problem with setting working coordinate systems ? Geoff
They are indeed not linked to buttons @GeoffH, as Ryan said they are JS. There is a system file (workplace.g) which is go to work zero and is linked to the button - I hope that stays as an editable file so I can add safe jogging via message boxes to it. Alex.
I'd expect that, so you have to remove G55 from your program, unless you really mean it. If you want to use G55, then you will need to select WCS 2 manually in the drop down before you Probe, Set XYZ etc. otherwise the program will be using a WCS that you haven't set. Geoff
Yes, good points, but I was responding to Ryan's point about wcs being changed outside of the drop down. It is something I need to look out for when checking what happens to wcs settings after outside machine limits errors to make sure it is not that which is causing it. Many of my g-code files have G55 in the header - I'll have to go through them and delete it. Alex.
I'm now thinking that the G53 may be the problem which is in workzero.g, maybe that's being incorrectly interpreted as a WCS?? It's possible that I've had the problem after doing a Goto Zero, I'll check it tomorrow - Geoff
Shouldn't be the G53 @GeoffH, it's not modal so should only apply to the line of g-code it is on - should revert to current WCS after that line. I hope its not because I was thinking of modifying my toolchange macros to use G53 in the light of the changes to DWC-2 to move to a consistent machine position. Alex.
Hi Alex and Ryan, yes that's exactly how G53 works and I've just tested it and that is correct, so I was wrong in my thinking last night. Anyway, I think I've found the culprit, my mistake, I had an old version of pause.g which had a G54 & G55 (what an idiot) in it, so apologies to everyone for wasting time, it's an age thing!! Alex are you sure that your problem was down to the G55 in the running program? Geoff
Not yet @GeoffH, I had forgotten about the first post on this thread where I modified the post processor to add G55 to the G-code and just picked some jobs at random from my SD card to test the new setup. I did notice the WCS in the drop down had changed but didn't give it any thought until Ryan suggested it might be the problem. Won't have time today to play, but will experiment more methodically tomorrow. Alex.
Ok, Alex I've done extensive tests, and now I've fixed the pause.g & resume.g macros everything looks good, so I'm happy that the WCS are working correctly. Geoff
That's good news @GeoffH. If I ever feel the need to use multiple wcs it will clearly need careful setting up. Alex.
Yes Alex, this is very true, I can't see a need yet, but you never know. Vectric doesn't appear to support anything like that, so it would probably come from Fusion or some gcode editing. Geoff
One small request @Ryan Lock, could we please have a bigger contrast between homed and unhomed axes - red and orange are a bit close together. Thanks, Alex.
When we officially release the firmware all the files will be setup correctly to work with multiple coordinates. But if you have any custom ones they would need changing. Basically though any work coordinate commands, G54, G55 etc should just be removed as everything happens in the current WCS now. With the old GUI we used G54 as a hack for machine coordinates to show them in the GUI. Ryan
To confirm what @GeoffH said I set workplace zero in three different wcs and then ran a g-code file in each of them. Duet correctly remembered the settings and ran the files correctly, so multiple wcs works correctly. Next test - g-code file with multiple work offsets - I'm not expecting any problems but will report back if it doesn't work. Alex. G-code file correctly changes wcs and runs files in correct position. Now to have a look at @ian McFadden's post processor for Fusion. Alex.
