Topics created by AndMaz

I see the same behaviour since a looong time. (Linux workstation) It is a bit surprising that I see that every time when I reboot the board and keep the telnet session open. (Which obviously disconnects than) The "Random chars" appear at a reconnect. The only "fix" I found is:
Disconenct from the telnet server
reset (to reset the linux terminal session)
Connect via telnet. That fixes it in 99%.

Cheers, Chriss

@gloomyandy I'm collecting telemetry every 10 secs so yeah, that definitely puts Duet under stress.

Re collecting the M122 data. Is there any docs for the Software reset code Error status and Aux0 errors ? I would like to understand the meaning of the reported vars

=== Platform === Last reset 17:44:30 ago, cause: power up Last software reset time unknown, reason: User, Gcodes spinning, available RAM 2276, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0

Note This was taken just now and without any OOM

@shugo1110 said in [Possible bug] Params parsing:

With the current allowed-chars-list i get an error when i do a

M98 P"0:/anymacro" S-1

That's a bug - thanks for reporting it. Workaround: use S{-1}.

until this fix i also could do a

M98 P"0:/sys/home.g" XYZ

this is resulting in an error now.

That's intentional. In most contexts, parameter letters must be followed by a value for that parameter. Older versions of RRF assumed a zero value if none was given, but that sometimes made it harder to diagnose what was wrong in the command line.

@AndMaz I creates this github issue https://github.com/Duet3D/RepRapFirmware/issues/865.

dc42 created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Add a means to check the type of a variable #865

@chrishamm tested and it works great. Super fast when compared to M36. Thank you again for your help

@AndMaz thanks for testing this.

@AndMaz I hope around the end of next week.

@chrishamm thank you for quick response.

That won't work because we need to free memory as quickly as possible, there isn't a huge amount of available RAM in standalone mode. RRF saves G-code replies per HTTP session and those sessions are keyed by IPv4 address. That concept would have to be changed first to allow for use-cases like yours.

The logic would be similar to the one that's currently in place. In other words, the reply contents would be deleted after the client has fetched them or if the client has not requested the reply within reasonable time (1 second). But I agree with you that this would imply re-working the current logic @ the firmware.

For now I will try to go with a mutex that will block concurrent reqs to the device. Hopefully, it this will avoid diagnostics data to "leak" into Commander service

@T3P3Tony don't know how to mark it as solved but here it goes

Update The original issue is solved https://github.com/Duet3D/RepRapFirmware/commit/f5fa23c3fd9eab9dc97cbefe317c3b0ee31cdf71 and released in v3.5beta2 (Link https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta2)

0 dc42 committed to Duet3D/RepRapFirmware Fix for FTP change to root directory (included in 3.5beta2 release)

@dc42 yeah, I've been looking at DWC and the logic that's implemented there. However, I still continue to think that /rr_reply response is not consistent and could be improved (or at least documented in detail).

In any case, thank you for your help 👍