Topics created by Garfield

@jay_s_uk well I'll be - never had to do that before - but it worked - many thanks

No worries, appreciated - you can always rely on users to do the unexpected. I never realy thought about the override file, never used it, suppose I should have realised what M501 actually did. It's one of those things you do early on then forget about - until it bites you .....

@tristanryerparke said in Duet 3 3.2 Beta2 + SBC jerking motion:

I believe this is the same issue as the what the OP had.

Ah, sorry, I didn't notice that you weren't the OP.

Yes please create a new thread.

Fair enough.

Regarding the macros, yes, something like this:

if state.status == "idle" remainder of macro commands note the indent

As mentioned - I have a MK3S - I kind of have it working now, that said if what you say is so then I find it a path down a route that I'd hoped Prusa wouldn't go, the filament library is great, I also add my own to it. To tie the library to 'specific' printers isn't a good idea, filaments are independent of ANY printer - the 'compatible approved printers' thing is the sort of BS I expect from certain major hi tech companies.

@Phaedrux said in Filament load ...:

@ChrisP said in Filament load ...:

Or you can manually edit filaments.csv in the sys folder.

That's the other way I was thinking of but couldn't brain.

While this is an option, I think it's the harder of the two as you have to get the filament name just right. I also forgot to say that this way will clearly require a reset after too to re-parse the filaments file.

@chrishamm said in Missing Fan(s):

Tacho inputs (Fan RPM) can be already seen in the Status panel.

Yes. And if they now have labels with names, or at least fixed possitions that all well and fine

I haven't re-enabled my filament sensor - flat out don't trust the printers behaviour.

This isn't the Pause.g - I can deliberately pause and resume with no problems whatsoever.

That the hot end did not move to a safe location as defined in the pause.g tells me that it isn't even executed, the message 'pausing' will never go away, there is no error indicated and I have a lot more confidence in my Hemera than I do the filament sensor currently.

At the point the print paused there were zero extrusion problems. As I mentioned I have no problem with the filament sensor being unreliable if I can resume with no problems - the big word here is IF ...

I've had numerous 'communication lost' reports so my belief is that the problem lies in how the Raspberry Pi and the Duet3 communicate - the communications is not resilient, it has been reported that the Duet framework crashes but it does not, it is still reported as running.

Part of the problem is that the console will lock you out whilst it executes some commands, if those commands never report complete then it appears frozen, it also doesn't seem to like messages being received that weren't solicited. There needs to be some improvement in the error handling and certainly a timeout on task execution cycles, I'm busy with other stuff or I'd look deeper.

Thanks for the file, I'll fix it in the next DSF version. the \uXXXX codes represent unicode characters, not sure why the JSON serializer thinks it is a good idea to encode them that way.

Thanks - all good to know - and yes that text is in there with no ; - and no complaints -

Deleted lines and failed to redo the P# ....

I shall try your adjustments - been pre-occupied trying to get a consistent and predictable first layer - some of the issues are in the slicer (tried Prusa and Simplfy3d - both are over extruding on the Hemera - may be similar to what another poster is seeing - first layer extrusion width > 0.42 is resulting in a rough surface and nozzle pickup layer height .07 over height) - topic for another day.

Not sure where I got these things from such as G92 - fairly sure it was documents / examples - I'll need to backtrack and see if I can figure that out - I shall dump the G92's.

I'll check the stepper direction vs current shortly - just doing another layer test ...

For me as a newcomer to Reprap 'in the raw' I'm struggling with what appear to be inconsistencies in how things are actioned in different commands.

Nowhere in the documentation have I found this to be adequately explained in my opionion as a newcomer i.e. what is based on nozzle co-ordinates and what is based on probe co-ordinates.

If I tell the system to probe X-157 Y-127 I don't expect to need to calculate the offsets and enter those instead since I've already told the printer (or machine) where the probe is in space relative to the nozzle.

I do realise that there are times where probing outside the 'print area' is required but this should be a deliberate selection regardless of the probing / levelling command - i.e if an option is missing the system won't violate print boundaries. I firmly believe that ALL actions should be based on nozzle co-ordinates for consistency, some commands being able to violate print boundaries and others not able to, there should be a hard boundary that no command can violate.

This issue has cost me in excess of $150 to replace damaged print surface components so I'm not terribly happy right now ....

@astrn said in Does M574 S4 work ?:

I wonder if this one works now? I encountered a similar problem with S4 command on my triple motor Z axis bed.

I have tested M574 X1 S4 on a Duet WiFi with 3 X motors connected, and it is working as intended.

@dc42 Thanks, appreciated, the temperature is within a degree of the hot end and bed so I can live with that, as you say the compensation provided isn't huge.

The Prusa Pinda came pretty high in accuracy and repeatability testing carried out by Tom Sanladerer and has been flawless on the Prusa hence my desire to continue using.

Well I'll be, I'm officially dumb as a box of rocks - it works - can you explain how the current reduction works ?

Is this a reduction in the actual current or the detection - seems a bit counter intuitive - I was reading all the stuff about how too slow and such is a problem.

Just trying to understand without code diving.

The Duetcontrolserver hang / fail is still happening, it is unpredictable but occurs most during homing. The web gui still functions for some things but is useless for any kind of control once this occurs.

Does anyone have a way to put this service into some sort of debug mode because there is nothing useful logged - it is almost as though the Pi doesn't know the service isn't working, this may be a communication failure between the web service and the control service and not actually a service failure.

The latest logs from the latest 'crash' - absolutely useless ..... I will be removing VNC since it serves no useful purpose to have a remote access to a browser window - that I already have access to.

pi@duet3:~ $ sudo journalctl -fu duetcontrolserver -- Logs begin at Sun 2020-03-08 00:17:01 GMT. -- Mar 09 12:03:00 duet3 DuetControlServer[13318]: DuetAPI.Commands.CodeParserException: Duplicate P parameter Mar 09 12:03:00 duet3 DuetControlServer[13318]: at DuetAPI.Commands.Code.Parse(TextReader reader, Code result, Boolean& enforcingAbsolutePosition) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPI/Commands/Code/Parser.cs:line 339 Mar 09 12:03:00 duet3 DuetControlServer[13318]: at DuetControlServer.FileExecution.BaseFile.ReadCode() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/FileExecution/BaseFile.cs:line 154 Mar 09 12:03:00 duet3 DuetControlServer[13318]: at DuetControlServer.FileExecution.MacroFile.ReadCode() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/FileExecution/MacroFile.cs:line 187 Mar 09 12:03:00 duet3 DuetControlServer[13318]: at DuetControlServer.SPI.ChannelInformation.ProcessRequests() in /home/christian/duet/DuetSoftwareFramework/src/DuetControlServer/SPI/ChannelInformation.cs:line 221 Mar 09 12:03:00 duet3 DuetControlServer[13318]: [warn] heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 875C. Mar 09 12:03:00 duet3 DuetControlServer[13318]: [info] Executing nested macro file config-override.g on channel Daemon Mar 09 12:03:00 duet3 DuetControlServer[13318]: [error] G31: Cannot set a temperature coefficient without a valid heater number Mar 09 12:03:00 duet3 DuetControlServer[13318]: [info] Daemon: Finished macro file config-override.g Mar 09 12:03:00 duet3 DuetControlServer[13318]: [info] Daemon: Finished system macro file config.g ^H ^C pi@duet3:~ $ sudo journalctl -fu duetwebserver -- Logs begin at Sun 2020-03-08 00:17:01 GMT. -- Mar 09 12:03:26 duet3 DuetWebServer[442]: at DuetAPIClient.BaseConnection.PerformCommand[T](BaseCommand command, CancellationToken cancellationToken) in /home/christian/duet/DuetSoftwareFramework/src/DuetAPIClient/BaseConnection.cs:line 178 Mar 09 12:03:26 duet3 DuetWebServer[442]: at DuetWebServer.Controllers.MachineController.DoCode() in /home/christian/duet/DuetSoftwareFramework/src/DuetWebServer/Controllers/MachineController.cs:line 100 Mar 09 12:03:26 duet3 DuetWebServer[442]: info: Microsoft.AspNetCore.Mvc.Infrastructure.ObjectResultExecutor[1] Mar 09 12:03:26 duet3 DuetWebServer[442]: Executing ObjectResult, writing value of type 'System.String'. Mar 09 12:03:26 duet3 DuetWebServer[442]: info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2] Mar 09 12:03:26 duet3 DuetWebServer[442]: Executed action DuetWebServer.Controllers.MachineController.DoCode (DuetWebServer) in 689487.1924ms Mar 09 12:03:26 duet3 DuetWebServer[442]: info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1] Mar 09 12:03:26 duet3 DuetWebServer[442]: Executed endpoint 'DuetWebServer.Controllers.MachineController.DoCode (DuetWebServer)' Mar 09 12:03:26 duet3 DuetWebServer[442]: info: Microsoft.AspNetCore.Hosting.Diagnostics[2] Mar 09 12:03:26 duet3 DuetWebServer[442]: Request finished in 689491.1494ms 500 text/plain; charset=utf-8 ^C pi@duet3:~ $ sudo journalctl -f -- Logs begin at Sun 2020-03-08 00:17:01 GMT. -- Mar 09 12:06:03 duet3 vncserver-x11[463]: AgentInitCheck: agent comms failure Mar 09 12:06:08 duet3 vncserver-x11[463]: AgentInitCheck: no response from agent Mar 09 12:06:08 duet3 sudo[15679]: pam_unix(sudo:session): session closed for user root Mar 09 12:06:13 duet3 vncserver-x11[463]: AgentInitCheck: agent comms failure Mar 09 12:06:18 duet3 vncserver-x11[463]: AgentInitCheck: no response from agent Mar 09 12:06:23 duet3 vncserver-x11[463]: AgentInitCheck: agent comms failure Mar 09 12:06:28 duet3 vncserver-x11[463]: AgentInitCheck: no response from agent Mar 09 12:06:33 duet3 vncserver-x11[463]: AgentInitCheck: agent comms failure Mar 09 12:06:36 duet3 sudo[15778]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/usr/bin/journalctl -f Mar 09 12:06:36 duet3 sudo[15778]: pam_unix(sudo:session): session opened for user root by pi(uid=0) Mar 09 12:06:38 duet3 vncserver-x11[463]: AgentInitCheck: no response from agent Mar 09 12:06:43 duet3 vncserver-x11[463]: AgentInitCheck: agent comms failure Mar 09 12:06:48 duet3 vncserver-x11[463]: AgentInitCheck: no response from agent Mar 09 12:06:53 duet3 vncserver-x11[463]: AgentInitCheck: agent comms failure

No worries. The configurator should probably be updated to use M669 now anyway.