RepRapFirmware 3.0 first official beta is out

Dougal1957

@bearer Nope same again permission denied

A Former User

@Dougal1957 Sorry, did a typo in the password, adding the username should help.

Dougal1957

@bearer unfortunately not

Dougal1957

now it seems to work not done anything either maybe a timer to stop me trying to often

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.

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
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.