Software bundle 3.3RC3 now available

tecno

Thank you, now updated

EducatingSavvas

@dc42 Playing around with the new RRF and CNC controls seems to be working. Just to confirm for CNC users - you will need to specify the tool first by having T# in the Gcode being processed, and then using M3 S# to turn on the spindle at the required RPM. Unless you include a tool number in your config.g file (which I don't) M3 S# wont turn on the spindle tool and you will need to include the spindle P# or select the tool by writing T# into the console. Many thanks.

Phaedrux

@educatingsavvas said in Software bundle 3.3RC3 now available:

select the tool by writing T# into the console

Not sure if it would apply to you, but for printer applications it would be typical to have T0 at the end of config.g to select the tool at startup. Alternatively you could add it to start.g so that it got executed when a job was started.

EducatingSavvas

@phaedrux Thanks but I'm not sure yet. I'm planning to use 4 tools on my CNC machine. T0 - laser, T1 - Spindle Router (main tool), T2 - Pen Tool in Spindle, and T3 - Tangential Knife. I'm still getting my head around workflow, working out offsets and g-code generation for multiple tool jobs.

war4peace

Attempted to upgrade from 3.3 RC2 to 3.3 RC3, mainly to fix the file simulation issue.
For the last 30 minutes, the upgrade process is stuck at 96%, with last message being "Sending update request to DCS..."

Setting up vlc-plugin-video-splitter:armhf (3.0.12-0+deb10u1+rpt2) ...
Setting up libvlc5:armhf (3.0.12-0+deb10u1+rpt2) ...
Setting up libraspberrypi-doc (1:1.20210527-1) ...
Setting up libraspberrypi-bin (1:1.20210527-1) ...
Setting up vlc-plugin-visualization:armhf (3.0.12-0+deb10u1+rpt2) ...
Setting up libraspberrypi-dev (1:1.20210527-1) ...
Setting up vlc-plugin-qt:armhf (3.0.12-0+deb10u1+rpt2) ...
Setting up libvlc-bin:armhf (3.0.12-0+deb10u1+rpt2) ...
Setting up rpi-eeprom (12.4-1) ...
Setting up vlc-plugin-base:armhf (3.0.12-0+deb10u1+rpt2) ...
Setting up vlc-plugin-skins2:armhf (3.0.12-0+deb10u1+rpt2) ...
Setting up vlc-bin (3.0.12-0+deb10u1+rpt2) ...
Setting up vlc (3.0.12-0+deb10u1+rpt2) ...
Setting up duettools (3.3-rc3) ...
Setting up duetwebserver (3.3-rc3) ...
Setting up duetsoftwareframework (3.3-rc3) ...
To modify config files consider adding yourself to the dsf groupd: # usermod -a       -G dsf <username>
Setting up duetwebcontrol (3.3-rc3) ...
Setting up duetcontrolserver (3.3-rc3) ...
Installing new version of config file /opt/dsf/conf/config.json ...
Setting up reprapfirmware (3.3-rc3-1) ...
Sending update request to DCS...
Progress: [ 96%] [#############################################################...]

It just sits there.
Do I attempt a forced reboot? Any idea?

The web interface is unavailable, tells me "Please wait while updates are being installed..." in a popup box.

EDIT: I have forced a reboot after 20 more minutes, and now DCS is not starting anymore.

CNCModeller

@educatingsavvas said in Software bundle 3.3RC3 now available:

@phaedrux Thanks but I'm not sure yet. I'm planning to use 4 tools on my CNC machine. T0 - laser, T1 - Spindle Router (main tool), T2 - Pen Tool in Spindle, and T3 - Tangential Knife. I'm still getting my head around workflow, working out offsets and g-code generation for multiple tool jobs.

@EducatingSavvas If you're using fusion 360 for CAM you configure tool selection there and it can be different for each tool path in each setup. It's worth a look if you haven't already. I use it all the time.

tom33

Hi,
since I upgrade to the 3.3 RC3 I have an issue with my motor. They don't move.
I Use duet3 with expansion board for external stepper driver.

war4peace

Update tom my previous post.
I had to connect the Duet 3 6HC to USB and to a laptop, and update the firmware using BOSSA.
Everything now works correctly.

war4peace

FYI:

[Duet + SBC] RRF updated job.lastFileName as soon as the print started. This confused DSF, causing it not to append the simulated time info to the file when a simulation completed. RRF no longer reports job.lastFileName while a print is in progress.

This is still not working, I have just simulated a file and the result was not updated in the job list.

Original topic.

cosmowave

I have a Duet2 Ethernet with FW3.3b3.
When i try to install 3.3rc3 then a error occurs:

Error: M997: In-application programming binary "0:/firmware/Duet2_SDiap32_WiFiEth.bin" not found

Phaedrux

@cosmowave said in Software bundle 3.3RC3 now available:

"0:/firmware/Duet2_SDiap32_WiFiEth.bin" not found

Are you uploading that file as well? Make sure it exists in the /firmware/ folder.

cosmowave

@phaedrux
oh no! I'm so stupid!
I have to load this file separately...
I will try it in the evening. Thanks!

dc42

@war4peace said in Software bundle 3.3RC3 now available:

Update tom my previous post.
I had to connect the Duet 3 6HC to USB and to a laptop, and update the firmware using BOSSA.

That's odd, the upgrade should have been straightforward.

war4peace

@dc42
I expected as much. After almost 1h of it being stuck at 96%, I rebooted the SBC. Then, I had to flash the motherboard firmware through BOSSA.
I guess the process got stuck while writing the firmware to the motherboard and it got corrupted.

Nevertheless, it's working now, however file simulation is still broken. Just FYI, maybe you'd like to take a look at it again.

dc42

@war4peace have you checked that you are definitely running Duet Control Server 3.3.0-rc3?

war4peace

@dc42
Yes sir.

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.3RC3 (2021-05-26 12:29:42) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6J9FL-3S86T-9TBYS
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 150784
Dynamic ram: 62264 of which 164 recycled
Never used RAM 138124, free system stack 126 words
Tasks: SBC(ready,5.3%,338) HEAT(delaying,0.0%,295) Move(notifyWait,0.0%,266) CanReceiv(notifyWait,0.0%,945) CanSender(notifyWait,0.0%,360) CanClock(delaying,0.0%,333) TMC(notifyWait,7.7%,59) MAIN(running,86.9%,922) IDLE(ready,0.0%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:42:39 ago, cause: power up
Last software reset at 2021-06-01 14:53, reason: User, GCodes spinning, available RAM 141196, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
Step timer max interval 133
MCU temperature: min 33.0, current 42.7, max 43.0
Supply voltage: min 23.9, current 23.9, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/438/438, gc cycles 0
Driver 0: position 40000, standstill, reads 9000, writes 20 timeouts 0, SG min/max 0/622
Driver 1: position 0, standstill, reads 9000, writes 20 timeouts 0, SG min/max 0/139
Driver 2: position 5080, standstill, reads 9001, writes 20 timeouts 0, SG min/max 0/136
Driver 3: position 0, standstill, reads 9001, writes 20 timeouts 0, SG min/max 0/956
Driver 4: position 0, standstill, reads 9001, writes 20 timeouts 0, SG min/max 0/122
Driver 5: position 0, standstill, reads 9006, writes 15 timeouts 0, SG min/max 0/0
Date/time: 2021-06-01 15:36:46
Slowest loop: 183.00ms; fastest: 0.03ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 42917ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 70, completed moves 70, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 2], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 22964, send timeouts 22961, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 49 (min 49), ts 12800/0/0
Last cancelled message type 30 dest 127
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 1ms ago
RX/TX seq numbers: 26317/26317
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x2c8bc
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.3-rc3
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 34.23
Codes per second: 0.06
Maximum length of RX/TX data transfers: 2920/848

chrishamm

@war4peace Thanks for your feedback. I've updated DSF once again to always wait for the simulated time to be set before trying to write it to the job file, I hope that will fix it once and for all. Likewise I've improved the firmware update code a bit - with my latest code I haven't got a single failed firmware update after approx 30 successive attempts.

garyd9

@chrishamm said in Software bundle 3.3RC3 now available:

with my latest code I haven't got a single failed firmware update after approx 30 successive attempts.

You aren't superstitious, are you? If I were to say something similar about my own code, it would have most certainly failed on the 31st attempt.

chrishamm

@garyd9 Just a bit - perhaps I should attempt it again 42 times

dc42

Off-topic, but 42 is a number worth avoiding in tests. In 7-bit binary, it's a palindrome (and 0x42 is a palindrome in 8-bit binary). A colleague of mine in a previous job was testing a prototype network interface, and for the test he chose to set the 7-bit node address to 42. The board worked. It was later discovered that the wiring of the node ID switches had the bit order reversed.