Posts made by mloidl

The simulated times left seems be to shown correctly after a print with 3.3.0-rc3.
Thanks a lot @mfs12 for the fix.

@mfs12 said in PanelDue Firmware 3.3.0-rc2 released:

slicer

Just saw your answer after pressing submit.
Your suggestion would be fine, but since slicerTime (job:timesLeft:slicer) is not a constant value this would lead to RRF changes too.

Edit:
I think i'm wrong. printTime in M36's response seems to be the slicer time, so it would be possible.

The current fields in the object model should not be changed, since they are fine and logical.
Simulated time is a static attribute of a file like file size, file name, .... both in M36 and in the M409 K"job" response (note: it's in the file structure => job:file:simulatedTime).

Best would be to extend the timesRemaining struct by adding a simulation field. This would not change the current behavior for backward compatibility but let RRF calculate the remaining time based on the simulated times as it is already done with the slicer time.

@mfs12 Yes. Maybe it's a misunderstanding from my side. I assumed the simulated time is decremented during the print because it's in the "Time left" section. Before v3.3 all times (layer, filament, ..) were decrementing too.

Hi,

The simulated time left is still not being recalculated during a print.

Both times (simulated & slicer) were nearly identical at the beginning of the print.

Versions

• RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) running on Duet WiFi 1.02 or later
• PanelDueFirmware 3.3.0-rc2 on v2-4.3. (same problem on 3.3.0-rc1)

I can confirm the start print / simulate print problem from 3.3.0-rc1 is fixed with 3.3.0-rc2

Thanks a lot @mfs12 for the fast fix.

@dc42 SD Card in the Duet. I have no SD-Card in the PanelDue inserted.

Now i've tried to do a real print an got an error because the file was not found.
.

Seems PanelDue is not sending the full path to RRF. The full path of the file was "0:/gcodes/Schuhloeffel_Hacken_0.2mm_PLA_2x.gcode".
Also renaming the file to a shorter filename without having a 'dot' in between did not work.

When starting the print from DWC the Times left (Simulated and from Slicer) are shown correctly but simulated time is never updated during the print.

If it's relevant:

Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.3 (2021-06-15)
Duet WiFi Server Version: 1.26

No print done so far, but clicked through the menus executed some macros and did a simulation.
No problems so far.

Simulated time was shown during the already simulated print after pressing "Simulate again".

I will do a real print in the evening.

Tested on a PanelDue: v2-4.3"

IMO the correct PA value is where YOU get the best results.

I'm having the same extruder on a Hypercube Evolution and the best PA value is exactly 0.1 for 'Spectrum PETG'.

I used the same method you did to get the PA-Value.

Just updated to DWC 2.1.1 and found out that the "Turn everything iff" - Button is not working. The following error is shown in the browser console.

vue.runtime.esm.js:1888 TypeError: Cannot read property 'forEach' of undefined
    at ToolsPanel.vue:407
    at c (runtime.js:45)
    at Generator._invoke (runtime.js:274)
    at Generator.forEach.e.<computed> [as next] (runtime.js:97)
    at Dt (asyncToGenerator.js:3)
    at o (asyncToGenerator.js:25)
    at asyncToGenerator.js:32
    at new Promise (<anonymous>)
    at asyncToGenerator.js:21
    at o.turnEverythingOff (ToolsPanel.vue:399)

Board: Duet WiFi 1.02 or later (duetwifi102)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.0 (2020-01-03b3)
Duet WiFi Server Version: 1.23

Regards,
Martin

@droftarts You could download the dmg-file only directly from github to save bandwidth.
https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.2.0

Seems since v3 macro execution started from PanelDue is queued until a non printing move is done. At least this is what i have observed so far.
For large print (especially the first layer), it may take a long time until the macro is executed.

This happens to me when i try to switch On/Off my lights with the macros on the PanelDue. When executed from DWC it is executed after some moves, as with RRF 2.0.5.

I will post my config later, since i currently have no access to it.

Edit:
Here are my config files. 1_Licht_ein.g and 2_Licht_aus.g are the macros mentioned in the post.

personal_config.g
estop_enable.g
estop_disable.g
config.g
2_Licht_aus.g
1_Licht_ein.g

see https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_Pin_names_for_Duet_2_WiFi_Ethernet

@jens55
'X' on the right upper corner is standard in Windows. This is not true for e.g. Mac OS X (left top corner). Also most Linux WM can be configured in a way the user want it.

DWC 2 is build around Material Design. This is the reason for the location of the 'X' Button. See https://material.io/components/dialogs/#full-screen-dialog for the specification.

Thanks @Danal.

You opened my eyes. Since your last post i thought it is possible to have multiple triggers for the same number.
Double checked this in the code. Tn is definitely the key.

So i have to change my emergency stop triggers a little bit otherwise they are not fully functional.

@Danal
Thank you for your fast reply.
Deactivating the trigger by M581 P"nil" seems to do the job.

Unclear to me is which triggers are deactivated.
I could image following situation (Pin names in the example are not real names)

M581 P"es1" T0 C0 ; es1 always leads to an emergency stop if activated
M581 P"es2" T0 C1; es2 is only activated during a print

M581 P"nil" T0 ; are both triggers deactivated?

Hi @dc42,

Did i miss something or is there no replacement for M581 S-1 for RRF3?
In RRF2 i was disabling the external triggers on my lower endstops during homing.

Since in RRF 3 the S Parameter was removed it seems not to be possible any more.

Do you have any suggestions?

Calling an empty trigger#.g - file would be an ugly option. Maybe there is some better idea.

Thanks.

Hi,

found this some time ago https://www.thespaghettidetective.com/, but i've never tried it.

@fcwilt

I have a magnetic build plate (not from buildtak) in use with a BL-Touch without problems so far