@gtj0, I can only think that you were running firmware 3.0 or another older firmware version.

@dc42 said in What's the best practice to test G-code during a debug session?:

@Sejl said in What's the best practice to test G-code during a debug session?:

@dc42 said in What's the best practice to test G-code during a debug session?:

You could try sending the command via the PanelDue serial port. Caution: it uses 3.3V signal levels; 5V will damage the MCU.

Duet 3 Hardware Overview web page says: "The inputs will tolerate up to 30V. The outputs are 3.3V signals levels with 470R series resistors."

I would like to know how can you damage MCU with 5V if input is tolerating up to 30V?

Best regards

I stand corrected. On Duet 3, PanelDue connects to the IO_0 connector, which is indeed tolerant of 30V on the input pin. On Duet 2 and Duet 085 it tolerates 3.3V maximum.

Thank you!

Thanks for quick reply!

So i understand there is no any protocol description and i can only rely on sources in this topic?

Moved to Firmware Developers forum.

Hmm, I don't think there is anything exactly like that in RRF. But to try and achieve your end goal of quieter fast travel moves maybe give M566 P1 a try.

https://duet3d.dozuki.com/Wiki/Gcode#Section_M566_Set_allowable_instantaneous_speed_change

The default jerk policy is 0, which replicates the behaviour of earlier versions of RRF (jerk is only applied between two printing moves, or between two travel moves, and only if they both involve XY movement or neither does). Changing the jerk policy to 1 allows jerk to be applied between any pair of moves.

I'll probably sort it out. Just venting a bit 🙂

@dc42 Not that I'm aware of... I've looked through the repetier repo and I can't find a document that covers the responses. I suspect that it would require going through the code.

@Danal said in RRF Version numbers and tagging:

To me, the bigger problem is lack of mapping from 'apt' releases to "V3.01 RC11" nomenclature.

Yeah, I don't use the packages because I compile and test a lot but it would make sense that the reprapfirmware package have the same version as the firmware it contained.

@dc42 Hi David

M575 P1 B57600 S1 ; Comms parameters for PanelDue

Updated the firmware in PanelDue yesterday to 1.24

Kind Regards,

Paul

@gtj0 said in Easier switching between DSF and Standalone mode?:

Given that "stay at home" has forced me to have 2 double-decker BLT sandwiches with extra mayo this week, I probably won't live that long.

Dang, man, I need to visit, lockdown or no.

It's all very confusing. Checked out everything again, and now RRF3 builds except at the end

make --no-print-directory post-build Generating binary file arm-none-eabi-objcopy -O binary "C:\Eclipse\Firmware\RepRapFirmware\Duet2_RTOS/Duet2CombinedFirmware.elf" "C:\Eclipse\Firmware\RepRapFirmware\Duet2_RTOS/Duet2CombinedFirmware.bin" && crc32appender "C:\Eclipse\Firmware\RepRapFirmware\Duet2_RTOS/Duet2CombinedFirmware.bin" c:/program files/gnu arm eclipse/build tools/2.6-201507152002/bin/sh: crc32appender: not found makefile:91: recipe for target 'post-build' failed

... and I just found https://forum.duet3d.com/topic/12275/crc32appender-now-needed-for-rrf/29

@bot Thank you, I will try your information.

I've submitted a pull request to have two SX1509 boards available:

https://github.com/dc42/RepRapFirmware/pull/379

Just built the binaries and I am going to go test it with my Duet2.

ajquick opened this pull request in dc42/RepRapFirmware open Add Support for 2 SX1509B I/O Expanders #379

Oddly enough, the instructions are in BuildInstructions in the dev and v3.01-dev branches but not in the v3-dev branch.

You need to copy the appropriate binary from Tools/crc32appender to someplace in your system PATH or update your system PATH to point to the directory where the appropriate binary is located. If you're on Linux, you can just copy Tools/crc32appender/linux-x86_64/crc32appender to /usr/local/bin.

@dc42 said in RC6 crash with M409:

Which Duet?

duet2eth

Most Duets have insufficient memory to return the whole OM in one go

ha, so new features... ok .. it worked on RC3/4 but yeah, more stuff added, all clear

Are you sure it crashed? What does M122 report for the software reset data?

Nope, not sure. Lost connection, then it returned, I assumed reboot, later on it just lot connection, did not return till power cycle. Will try now

M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.01-RC6 running on Duet Ethernet 1.02 or later Board ID: 08DGM-9T6BU-FG3S4-6J9FD-3SD6Q-KVRBF Used output buffers: 1 of 24 (24 max) === RTOS === Static ram: 28052 Dynamic ram: 93604 of which 20 recycled Exception stack ram used: 496 Never used ram: 8900 Tasks: NETWORK(ready,164) HEAT(blocked,1244) MAIN(running,1576) IDLE(ready,80) Owned mutexes: === Platform === Last reset 02:46:59 ago, cause: software Last software reset time unknown, reason: User, spinning module GCodes, available RAM 8892 bytes (slot 3) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 4 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 7.1ms, max retries 0 MCU temperature: min 42.6, current 44.7, max 45.1 Supply voltage: min 23.9, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: standstill, SG min/max 0/350 Driver 1: standstill, SG min/max 0/356 Driver 2: standstill, SG min/max 0/1023 Driver 3: standstill, SG min/max not available Driver 4: standstill, SG min/max not available Date/time: 2020-04-10 15:32:11 Cache data hit count 4294967295 Slowest loop: 15.72ms; fastest: 0.12ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Move === Hiccups: 0(0), FreeDm: 169, MinFreeDm: 166, MaxWait: 439095ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 140, completed moves: 140, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = 0 -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 ready with "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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 39.51ms; fastest: 0.02ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 1 of 8 Interface state active, link 100Mbps full duplex === Filament sensors === Extruder 0 sensor: no data received

iI you really do want to read the whole OM, the recommended approach is;

I just wanted to dump the whole thing few times quckly and then diff the outputs to see what changed 😄 .. not something I need to use normally in production 🙂 ... it's totally ok as is, the lack of RAM did not came to mind 🙂

I can live with that! Typos in errror mesagges are another thing.

Pesky libraries. 🙂

It worked very well!
Thanks for the excelent service!!

@aidar Thanks for looking at this.
2.07 is on both.
Downloaded DWC again so I have a fresh copy.

Reinstalled, put my parameters back in and all is good. 😕

I will close this.

Thanks.

@dc42 interpolation isn't real stepping.
It's better than not having it, but it's 0,0125 mm accuracy versus 0,00078125 mm accuracy.
I sure don't need 0,001 mm accuracy for my application because material itself can't be this much accurate, but 0,01 can some times be visible (this is why I switched to full 256 microsteps.
I've tried 1/64 before switching to 1/256, it did improved some surfaces but not as much as 1/256 did.

What's about Duet 3?
Does it have the same issue or should I start saving for an upgrade?