Unsolved Meta commands underscore '_' no longer valid?

[Nxt-1]

I was surprised to find out that my bed.g file was all of a sudden throwing out errors (after upgrading from a Wifi to a 3 6HC). I get a Error: expected '=' in line 11 of bed.g error. After some testing it turns out the _ in the variable name is causing this issue. I have been using this exact bed.g file without issue, so I am not sure what happend here?

My bed.g file: bed.g and the output of M122 for versions (v3.3.0):

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-9P63L-DJMSS-6JKD0-3S06T-9AF79
Used output buffers: 4 of 40 (14 max)
=== RTOS ===
Static ram: 150904
Dynamic ram: 60460 of which 176 recycled
Never used RAM 139796, free system stack 119 words
Tasks: SBC(ready,4.9%,215) HEAT(notifyWait,0.0%,325) Move(notifyWait,0.0%,266) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,358) CanClock(delaying,0.0%,333) TMC(notifyWait,7.3%,59) MAIN(running,87.7%,1131) IDLE(ready,0.0%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:30:00 ago, cause: software
Last software reset at 2022-01-14 13:32, reason: User, none spinning, available RAM 142828, slot 1
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 167
MCU temperature: min 33.7, current 33.9, max 34.1
Supply voltage: min 30.6, current 30.6, max 30.7, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/166/150, gc cycles 0
Driver 0: position 1186446, standstill, reads 6641, writes 0 timeouts 0, SG min/max not available
Driver 1: position 1186446, standstill, reads 6641, writes 0 timeouts 0, SG min/max not available
Driver 2: position 1186446, standstill, reads 6641, writes 0 timeouts 0, SG min/max not available
Driver 3: position 0, standstill, reads 6643, writes 0 timeouts 0, SG min/max not available
Driver 4: position 0, standstill, reads 6642, writes 0 timeouts 0, SG min/max not available
Driver 5: position 0, standstill, reads 6642, writes 0 timeouts 0, SG min/max not available
Date/time: 2022-01-14 14:02:12
Slowest loop: 0.45ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
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, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 1381, completed moves 1381, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 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, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Segments left: 0
Movement lock held by 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 assembling a command 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
Code queue is empty.
=== CAN ===
Messages queued 2118, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 49 (min 49), ts 1177/0/0
Tx timeouts 0,0,1177,0,0,941 last cancelled message type 30 dest 127

=== SBC interface ===
State: 4, failed transfers: 0, checksum errors: 0
Last transfer: 3ms ago
RX/TX seq numbers: 65043/65043
SPI underruns 0, overruns 0
Disconnects: 0, timeouts: 0, IAP RAM available 0x2c83c
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.3.0
Code buffer space: 4096
Configured SPI speed: 8000000Hz
Full transfers per second: 35.84, max wait times: 47.2ms/0.0ms
Codes per second: 0.00
Maximum length of RX/TX data transfers: 4392/836

[dc42]

@nxt-1 underscores in variable names work for me in RRF beta7+7, so if this was a bug then I think it is already fixed in 3.4.

[Nxt-1]

@dc42 Well, underscores used to work for me in 3.3 as well, over on my duet wifi. That's why this is so weird to me.

[dc42]

@nxt-1 please test again using the 3.4beta7+7 files at https://www.dropbox.com/sh/i5vox3xmkd55gaz/AAC19mI0WEC5GmEjLOBRbKs-a?dl=0. If you are running your Duet with attached single board computer then you will need to upgrade to 3.4.0beta7 via the package server first.

I can't see any reason why the acceptance of underscores or not in variable names would depend on context.

[Nxt-1]

@dc42 The 6HC is indeed running in SBC mode (with a jetson nanom for wich I plan to write a setup guide in the soon future) I am not willing to go the beta firmware route at this point.
I did however boot up the old wifi again and did a quick sanity check. That Duet is running V3.3.0 (RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) running on Duet WiFi 1.0 or 1.01) and there the underscore is in fact allowed.

[dc42]

@nxt-1 so do you think this may be an issue in SBC mode but not in standalone mode?

[Nxt-1]

@dc42 I am not familiar enough with the different versions of the firmware these days (I am not following FW development as closely as I used to ). But my guess would indeed be SBC/standalone or Duet2/Duet3 hardware. I must again disapoint as I cannot test standalone mode on the Duet 3 since clever me a couple of months ago decided RJ45 access was not needed when designing the mount of the board.

Another small update, as a temp fix I removed all the underscores and re-ran the file. This time I got an Error: Failed to read code from macro bed.g: Unexpected closing round brace in line 104
Again something is fishy here, even calling

echo ")"

in console throws that error. This leads me to belive there is something wrong with properly escaping special characters in general for some reason.

[dc42]

@nxt-1 thanks for reporting this. That echo command work in standalone mode, so I've logged this as a bug in SBC mode.

[Nxt-1]

@dc42 I am just adding things I notice to behave differently as I go here. The bed.g script used to output some logs between each iteration of the loop. Now it waits for the whole thing to finish and then prints all at once, in reverse chronological order. So the messages that should be the most recent get printed at the bottom of the blob in console.

[chrishamm]

@nxt-1 This is already fixed in 3.4-b7, any chance you can give that a try?

[Nxt-1]

@chrishamm Again, my appologies. I need my printer at the moment and am not using beta firmware. I will consider a release candidate once a find the time to read up on all the changes.