2 SD Cards - SBC - stop after pause.g 3.5beta2
-
How did you switch to SBC mode?
What SD card did you use?
How did you transfer your config files over?
Is there still an SD card in the Duet?
From your photo it shows the normal contents of the standalone SD card being present in the Jobs tab, which would be the gcode folder. This is not correct.
Can you send M122 and copy and paste the results here? -
@Phaedrux
How did you switch to SBC mode?
-- I formatted a sd card and booted duetPi with balena
What SD card did you use?
-- pictures. I used different ones
How did you transfer your config files over?- in dwc i opened system files where just a blank congig was. I uploaded my old gcode and erased all my mistakes.( had some errors).
Is there still an SD card in the Duet? - no
From your photo it shows the normal contents of the standalone SD card being present in the Jobs tab, which would be the gcode folder. This is not correct.
Can you send M122 and copy and paste the results here?
m122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.5beta2 (2023-02-08 15:27:50) running on Duet 3 MB6HC v1.01 (SBC mode) Board ID: 08DJM-956L2-G43S4-6J9D6-3S46P-KU42D Used output buffers: 1 of 40 (17 max) === RTOS === Static ram: 154344 Dynamic ram: 84228 of which 0 recycled Never used RAM 106900, free system stack 200 words Tasks: SBC(ready,0.8%,428) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.0%,342) CanReceiv(notifyWait,0.1%,771) CanSender(notifyWait,0.0%,335) CanClock(delaying,0.0%,340) TMC(notifyWait,7.8%,90) MAIN(running,91.2%,446) IDLE(ready,0.0%,30), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:37:48 ago, cause: software Last software reset at 2023-04-13 20:25, reason: User, FilamentSensors spinning, available RAM 105844, slot 1 Software reset code 0x600d HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 Step timer max interval 137 MCU temperature: min 32.1, current 32.4, max 34.1 Supply voltage: min 23.7, current 23.8, max 23.8, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0 Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Events: 0 queued, 0 completed Driver 0: standstill, SG min n/a, mspos 559, reads 41685, writes 14 timeouts 0 Driver 1: standstill, SG min n/a, mspos 559, reads 41685, writes 14 timeouts 0 Driver 2: standstill, SG min n/a, mspos 559, reads 41685, writes 14 timeouts 0 Driver 3: standstill, SG min n/a, mspos 559, reads 41685, writes 14 timeouts 0 Driver 4: standstill, SG min n/a, mspos 8, reads 41688, writes 11 timeouts 0 Driver 5: standstill, SG min n/a, mspos 440, reads 41685, writes 14 timeouts 0 Date/time: 2023-04-13 21:03:12 Slowest loop: 2.41ms; fastest: 0.05ms === Storage === Free file entries: 20 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, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000 no step interrupt scheduled === DDARing 0 === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === DDARing 1 === Scheduled moves 0, completed 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, chamber heaters -1 -1 -1 -1, ordering errs 0 === GCodes === Movement locks held by null, 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 File2 is idle in state(s) 0 Queue2 is idle in state(s) 0 Q0 segments left 0, axes/extruders owned 0x0000000 Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === CAN === Messages queued 20467, received 181424, lost 0, boc 0 Longest wait 13ms for reply type 6018, peak Tx sync delay 870, free buffers 50 (min 49), ts 11341/11340/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 21678/21678 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x26934 Buffer RX/TX: 0/0-0, open files: 0 === Duet Control Server === Duet Control Server version 3.5.0-beta.2 (2023-02-08 11:47:09) Code buffer space: 4096 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 38.48, max time between full transfers: 138.4ms, max pin wait times: 55.3ms/1.7ms Codes per second: 0.03 Maximum length of RX/TX data transfers: 4436/984
But I used different cards and I alsways had the same problem.
- in dwc i opened system files where just a blank congig was. I uploaded my old gcode and erased all my mistakes.( had some errors).
-
Your photos show the jobs tab. This is where sliced gcode files go, not config files. Those should be in the system tab.
-
@Phaedrux
yes I know.
I have config etc at systems folder. Strange --> at jobs the SECOND sd card (Is it right that there are 2? ) is all this folder stuff. but it´s EDIT; config is empty, the firmware files are existing there.
I deleted it by inserting the sd card. Now it´s not booting anymore.
At Jobs folder its like that
SD Card 0: - jobs
SD Card 1: what you see on picture but almost empty config. just blank from duetpi -
Do you have a second SD card inserted in a PanelDue or something?
The actual files for the SBC Duet config is contained in the SBC file system.
The first SD card (0:/) is emulated by DCS and its default directory is /opt/dsf/sd
-
I would suggest maybe starting fresh with a clean SD card and a fresh download of DuetPi. I would also stay on 3.4.5 until everything is working, and then only updating to a beta release if you want to test something or need a specific fix.
-
@Phaedrux
No, just sbc with card.
Maybe
But the system is booting from sd card 0.
I also cant delete config.g from s cards jobs folder.
-
@Phaedrux
Sadly I have to use any of 3.5 versions cause of closed loop steppers. I have a double y axis and it was not sufficient to print before.
Now, everything is fine. In standalone mode I dont have this problem, so for important jobs I could go back to standalone mode, but I want to use some plug ins etc I need raspberry for.I don´t have a fresh sd card here.. do you mean completly new?
They´re all quite old and I have lot´s of failed flashs with balena. Is that normal?May I really start from beginning.
Can I also use M122 P104 S20 with sbc?
I had 0.1mb yesterday....I would like to go ahead with investigation, If start from beginning is not helpful. I think, if you could answer some question then, I would be happy.
-
I would try doing a full format on one of the sandisk ultra SD cards using the SD card formatter tool. Then try imaging it again with etcher. Failed flashes are not normal, no.
@IndeX4D said in 2 SD Cards - SBC - stop after pause.g 3.5beta2:
Can I also use M122 P104 S20 with sbc?
I don't think so, but maybe.
@IndeX4D said in 2 SD Cards - SBC - stop after pause.g 3.5beta2:
Sadly I have to use any of 3.5 versions cause of closed loop steppers.
Ah, I understand. Even so, it would be good to see how it behaves in 3.4.5 before updating to the 3.5 beta.
-
@Phaedrux OK I format the cards and I´ll try it again to flash.
Should I take the newest duetpi version?I´ll try 3.4.5. in a few min.
Edit: Also when Flash Failed, I have the problem with 2 Sd Cards and printer is running.
thanks
-
After format, flash is failed. Also with the other sd cards. But I can start duet and print with same problems.
It makes no sense to go ahead with testing when flashing failed, right?
-
what is the error when the flash fails?
-
This post is deleted! -
Strange that I can still print with failed flashing, but my problem occured with a succesful flash.
Can you say what kind of error it is?
-
I don't know. But it looks like it failed on verify near the end with a strange error. Maybe try re-installing etcher with a fresh download. Or try a different SD card flasher.
Did you do a full format of the SD card? That's a good way to force it to remap any bad sectors and make sure it's entirely writable.
As for what is happening with the second SD card showing, perhaps @chrishamm knows.
-
@Phaedrux
Strangely flashing is failed earlier. Feels like the sd cards are more crazy with every step.
I'll buy new sd card, flash from different computer and use different raspberry.
I'll tell my experience later. -
@IndeX4D In SBC mode do NOT touch any files on the second SD card partition (which is
/boot
on the SBC system or the first FAT partition). This partition contains boot files for the SBC Linux system and several files for standalone mode, so if you delete arbitrary files from there, your SBC will not start any more.You can use the Raspberry Pi Imager if the other flash tools fail - just make sure you don't have read-only protection set on your SD adapter.
M122 P104
is not supported in SBC mode, there are other Linux utilities for the same purpose. -
@chrishamm thanks for your answer
I´ll try everything again with completly new setup in a few minutes,
-
Is it ok to run sbc with ethernet not only temporary?
-
What do you mean?