RepRapFirmware 3.0 first official beta is out

[Dougal1957]

@Dougal1957 next Question from an ssh session how do I enable VNC and if possible set a static IP?

[A Former User]

you can follow any raspbian guide for that, run lsb_release -ato see which distro codename (strech or buster likely) they used.

[Dougal1957]

it is indeed buster rel 10. also need to do the firmware updates as it has 3 v0.6 on it at the moment (Managed to get into the DWC Pages using Chrome Safari didn't the first time I tried it it does now doh.

Google time.

[kraegar]

@T3P3Tony Unfortunately I did not.

I'll do some more prints today and see if I can get one that fails. Hopefully on a shorter print.

[T3P3Tony]

@Dougal1957 the easiest way is

sudo raspi-config

Its not enabled by default to speed up boot for those that don't need it.

[Dougal1957]

@T3P3Tony Thanks tony I found that and have enabled it but now I know it can soon be disabled I still don't know why it wasn't letting me in via ssh and then started working but all good now next step is setting a static IP for it on my network.

Doug

[A Former User]

@Dougal1957 said in RepRapFirmware 3.0 first official beta is out:

next step is setting a static IP for it on my network.

seems its the same for buster as stretch, have a look at sudo nano /etc/dhcpcd.conf should be an example in that file.

[kraegar]

Heater faulted this time, print shows 100%, but it still moving as if printing.

9/15/2019, 5:20:46 PM: M122: === Diagnostics ===
RepRapFirmware for Duet 3 v0.5 version 3.0beta10 running on Duet 3 prototype v0.5
Board ID: 08DGM-9T66A-G63SJ-6J1FJ-3SD6M-KS0BA
Used output buffers: 1 of 32 (7 max)
=== RTOS ===
Static ram: 67696
Dynamic ram: 133764 of which 60 recycled
Exception stack ram used: 592
Never used ram: 191104
Tasks: NETWORK(ready,2044) HEAT(blocked,1108) CanReceiv(suspended,3804) CanSender(suspended,1496) CanClock(blocked,1432) TMC(blocked,456) MAIN(running,1856) IDLE(ready,196)
Owned mutexes:
=== Platform ===
Last reset 02:57:41 ago, cause: power up
Last software reset at 2019-09-13 01:57, reason: Unknown, spinning module Platform, available RAM 191532 bytes (slot 3)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
Error status: 0
MCU temperature: min 47.1, current 57.2, max 58.3
Supply voltage: min 22.2, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, reads 26365, writes 25 timeouts 0, SG min/max 0/1023
Driver 1: ok, reads 26366, writes 25 timeouts 0, SG min/max 0/1023
Driver 2: standstill, reads 26367, writes 25 timeouts 0, SG min/max 0/1023
Driver 3: standstill, reads 26368, writes 25 timeouts 0, SG min/max 0/877
Driver 4: standstill, reads 26370, writes 25 timeouts 0, SG min/max 0/312
Driver 5: standstill, reads 26379, writes 17 timeouts 0, SG min/max 0/1023
Date/time: 2019-09-15 22:20:44
Slowest loop: 285.52ms; fastest: 0.19ms
=== Move ===
Hiccups: 366674, FreeDm: 354, MinFreeDm: 285, MaxWait: 354199ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 19586, completed moves: 19533, StepErrors: 0, LaErrors: 0, Underruns: 0, 1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 1
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file* is doing "G1 X119.443001 Y109.000999 E0.012100" in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon* is ready with "M122" in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
spi is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 79.80ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8

• Ethernet -
  State: 0
  Socket states: 0 0 0 0 0 0 0 0
  === Linux interface ===
  State: 0, failed transfers: 0
  Last transfer: 113ms ago
  RX/TX seq numbers: 30927/30927
  SPI underruns 0, overruns 0
  Number of disconnects: 1
  Buffer RX/TX: 1760/64-2024
  === Duet Control Server ===
  Duet Control Server v1.0.3.1
  File:
  Pending code: G1 X129.877 Y112.387 E0.0176
  Pending code: G1 X130.284 Y112.666 E0.0197
  Pending code: G1 X131.002 Y112.891 E0.0301
  Buffered code: G1 X123.744 Y110.305 E0.0091
  Buffered code: G1 X124.791 Y109.809 E0.0463
  Buffered code: G1 X125.212 Y110.439 E0.0303
  Buffered code: G1 X125.880 Y110.144 E0.0292
  Buffered code: G1 X125.991 Y110.120 E0.0046
  Buffered code: G1 X126.642 Y110.149 E0.0261
  Buffered code: G1 X127.095 Y110.256 E0.0186
  Buffered code: G1 X127.175 Y110.861 E0.0244
  Buffered code: G1 X126.957 Y111.087 E0.0126
  Buffered code: G1 X126.976 Y112.073 E0.0394
  Buffered code: G1 X127.879 Y112.308 E0.0373
  Buffered code: G1 X128.115 Y112.413 E0.0103
  Buffered code: G1 X128.511 Y112.350 E0.0161
  Buffered code: G1 X128.605 Y112.302 E0.0042
  Buffered code: G1 X129.359 Y112.364 E0.0303
  Buffered code: G1 X129.418 Y111.958 E0.0164
  Buffered code: G1 X129.802 Y111.953 E0.0154
  => 748 bytes
  Code buffer space: 1104
  Configured SPI speed: 1000000 Hz
  Full transfers per second: 269.94
  Processing print job /opt/dsf/sd/gcodes/forbiddentower-whole-02_100mm.gcode

[wilriker]

@kraegar said in RepRapFirmware 3.0 first official beta is out:

Heater faulted this time, print shows 100%, but it still moving as if printing.

IMHO "heater faulted" is a bit misleading since it has a specific meaning usually. Maybe something more descriptive like "heaters turned off" would be better.

=== Move ===
Hiccups: 366674, FreeDm: 354, MinFreeDm: 285, MaxWait: 354199ms

Not sure if that's the cause for the problem but this section does not look good either way.

EDIT: the hiccups might be a result of the extruder drive not being moved because of too low temp.

[dc42]

@wilriker said in RepRapFirmware 3.0 first official beta is out:

EDIT: the hiccups might be a result of the extruder drive not being moved because of too low temp.

That shouldn't cause hiccups. A hiccup is a deliberate delay introduced by the step pulse generator when it finds that it can't keep up with step rate demanded. They typically happen when microstepping is set too high.

[T3P3Tony]

@kraegar thanks for persevering. I note that you are showing :

=== Duet Control Server ===

Duet Control Server v1.0.3.1

in your M122, even though earlier you reported 1.0.3.3 as installed. can you try a restart and confirm that you are now using 1.0.3.3

I am not 100% sure this is fixed in 1.0.3.3 but it should be better

[kraegar]

I have seen two failure scenarios.

1. It says heater 0 faulted, temps all drop, % complete goes to 100% and it keeps on moving in x/y/z through the gcode file. I can't cancel the print, even though it's still chugging along
2. It just stops entirely. Also reports 100% complete.

@T3P3Tony - good catch. It's interesting, yes I have only 1.0.3.3 installed now according to apt list, but it reports back as running 1.0.3.1. This was after multiple full reboots since I'd pulled 1.0.3.3. It must not have updated right when I switched repo's. I uninstalled it (sudo apt-get remove duetsoftwareframework; sudo apt autoremove ), rebooted for good measure, then pulled a fresh copy. M122 now reports the correct version that matches the CLI.

[T3P3Tony]

@kraegar ok, at least some of those issues are supposed to be fixed in 1.0.3.3 so please try again!

[kraegar]

Yep, already starting a print!

Sorry, if I'd noticed M122 had a different version earlier I wouldn't have bothered till that was fixed!

(It may be worth investigating how your updates work, since the CLI showed a later version than what was running, something didn't get overwritten properly)

[T3P3Tony]

@kraegar yes - i think we need to force stop the service before the update runs

[kraegar]

Is it possibly to query against the duet services from the CLI now? A diag script to list versions, compare the running version against the installed version, etc would be trivial, and handy if so. I'm sure more could be added to it over time, too.

[A Former User]

@kraegar said in RepRapFirmware 3.0 first official beta is out:

Is it possibly to query against the duet services from the CLI now?

maybe the link in this post has some inspiration; not been updated to reflect the new repository however https://github.com/chrishamm/DuetSoftwareFramework/issues/31#issuecomment-513701442

if you meant to run g-code from the console you might want to look at this (CodeConsole is very unpolished)

pi@duet3:/opt/dsf/bin $ sudo ./CodeConsole
Connected!
M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 ...
pi@duet3:/opt/dsf/bin $

beikeland created this issue 21 Jul 2019, 23:17 in chrishamm/DuetSoftwareFramework

closed M115 does not work on serial/USB #31

[T3P3Tony]

@kraegar you can see what services are running in the normal linux way. but not what firmware is on the duet w/o writing a plugin for DSF (or as @bearer says use codeconsole)

[kraegar]

@T3P3Tony Yeah, I meant querying the duet itself. I'll take a look at codeconsole, and the other threads. Sounds like there's been some good work done already, so I probably won't muddy the waters.

[kraegar]

Longest completed duet3 print @ 3h 5m without issue now that I'm running the latest software. I'll keep on testing!