Variable "already exists"

DonStauffer

@fcwilt The files are there, including config.g, which shows zero bytes!

DonStauffer

@fcwilt And config.g.bak with a date an hour earlier. Maybe I should rename config.g, then rename config.g.bak to config.g. Or copy it. Not sure which.

fcwilt

@donstauffer said in Variable "already exists":

@fcwilt And config.g.bak with a date an hour earlier. Maybe I should rename config.g, then rename config.g.bak to config.g. Or copy it. Not sure which.

I've seen that happen before.

The backup file should contain everything but the very last edits you made.

If config.g is empty then you can delete it (or rename it) and then rename the backup - all should be good except for the lost edits.

Frederick

DonStauffer

@fcwilt First thing I just copied the entire SD card to my raid array. Then I renamed the files. Now I'll see what happens.

DonStauffer

@fcwilt OK, that worked. And the last couple changes I made were to add and then delete a space to the file, so essentially, the backup has everything. Wow. That shouldn't have happened.

DonStauffer

@fcwilt Anyhow, nice little bit of drama. Thanks for keeping me grounded there for a bit.

As to variables, I may just put in the test because it won't clutter the globals, and the whole purpose for them being in the file was that you could change them as needed. They function like constants in a normal language. So making them global would be counterproductive for this purpose.

But I wonder if this is by design. I doubt it.

fcwilt

@donstauffer said in Variable "already exists":

@fcwilt Anyhow, nice little bit of drama. Thanks for keeping me grounded there for a bit.

As to variables, I may just put in the test because it won't clutter the globals, and the whole purpose for them being in the file was that you could change them as needed. They function like constants in a normal language. So making them global would be counterproductive for this purpose.

But I wonder if this is by design. I doubt it.

If you are going to do the tests it might be easier to read if you had a section where you just tested and created the variables if needed and another section where you just set them knowing they either already exist OR they have just been created by the section above.

Otherwise you would have a bunch of if/else where the needed value appeared twice, once for the creation and once for the setting.

Frederick

kb58

@donstauffer said in Variable "already exists":

@fcwilt The files are there, including config.g, which shows zero bytes!

Interesting... I had this exact thing happen several weeks ago and am pretty sure it was due to a corrupted write. I had to delete config.g and renamed config.bak as config.g. The other way was to remove the SD drive and fix it in the PC - I always keep duplicates of the SD files on the PC for just this sort of reason.

DonStauffer

@fcwilt I see what you mean. Create them with dummy values like zero, if they need to be created. That way the values only need to be tracked in one place. Not sure if you can create them without assigning a value. The documentation seems to say not.

Phaedrux

@donstauffer said in Variable "already exists":

What I've been doing is editing config.g - just putting in a space, deleting it, then saving it, and telling it yes to restart the board.

Kind of a weird way to do it. Hitting the emergency stop button in DWC. Or sending M999 for a soft reset would be cleaner.

How often do you think you've done that to reset the board? I wonder if you've triggered a bug that fails to write the config.g.

DonStauffer

@phaedrux Maybe a half dozen times a day. Usually I turn the machine off over night if I'm not printing anything long. I didn't know about M999 and I sort of thought emergency stop just kind of hung the machine and I had to turn it off anyway. Not sure. I haven't done it much.

Phaedrux

The emergency stop button basically runs M112 to do a full halt, and then resets the firmware with M999.

https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M112_Emergency_Stop

https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M999_Restart

Phaedrux

Was there anything unique to the time that it erased the config.g file?

For the sake of completeness, could you share the config.g and the results of M122?

DonStauffer

@phaedrux No, nothing unique I can think of. Just that message. I've attached config.g.bak to this message. It's the latest version of the file that I have. Its contents should be precisely what was in the file when it happened.

[0_1628740265183_config.g.bak](Uploading 100%)

DonStauffer

@phaedrux

8/11/2021, 10:52:45 PM M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3SN-6JKD0-3S06Q-9AY7D
Used output buffers: 3 of 24 (15 max)
=== RTOS ===
Static ram: 23876
Dynamic ram: 76604 of which 0 recycled
Never used RAM 11080, free system stack 188 words
Tasks: NETWORK(ready,10.1%,246) HEAT(delaying,0.0%,330) Move(notifyWait,0.1%,340) DUEX(notifyWait,0.0%,24) MAIN(running,83.8%,442) IDLE(ready,6.0%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:00:12 ago, cause: software
Last software reset at 2021-08-11 22:52, reason: User, GCodes spinning, available RAM 10856, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 46.2, current 46.7, max 47.0
Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/4, heap memory allocated/used/recyclable 2048/32/0, gc cycles 0
Driver 0: position 0, standstill, SG min/max not available
Driver 1: position 0, standstill, SG min/max not available
Driver 2: position 0, standstill, SG min/max not available
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0, standstill, SG min/max not available
Driver 6: position 0, standstill, SG min/max not available
Driver 7: position 0, standstill, SG min/max not available
Driver 8: position 0, standstill, SG min/max not available
Driver 9: position 0, standstill, SG min/max not available
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-08-11 22:52:44
Cache data hit count 470797477
Slowest loop: 4.44ms; fastest: 0.17ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 0.9ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, 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, chamberHeaters = -1 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== DueX ===
Read count 1, 4.85 reads/min
=== Network ===
Slowest loop: 151.71ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8

WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.26
WiFi MAC address 84:f3:eb:83:47:be
WiFi Vcc 3.36, reset reason Power up
WiFi flash size 4194304, free heap 26496
WiFi IP address 192.168.1.130
WiFi signal strength -43dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 4 0 0 0 0 0 0 0

fcwilt

@donstauffer said in Variable "already exists":

@fcwilt I see what you mean. Create them with dummy values like zero, if they need to be created. That way the values only need to be tracked in one place. Not sure if you can create them without assigning a value. The documentation seems to say not.

You would need to assign some placeholding value, like zero, I'm sure you could determine suitable values in each case.

Frederick

dc42

@donstauffer said in Variable "already exists":

I have my slicer set to insert a few variable definitions (var, not global) into the gcode files it produces. Works fine, except if I then upload and try to print another file without first restarting the duet, I get this "already exists" error, even though the original file completed and I started another.

Is that the way it's supposed to work?

I agree, it would make sense to treat local variables created in a print file the same as variables created in a macro file and remove them when the file completes or is cancelled. I will add a work item to fix this.

DonStauffer

@fcwilt The problem with conditionally defining local variables is:

"The scope of a local name is the remainder of the block in which it is declared."

So, this will produce "unknown variable":

if !exists(var.xxx)
	var xxx=0
set var.xxx=4

I'm trying to think of a workaround I can use right now, besides just making them globals.

fcwilt

@donstauffer said in Variable "already exists":

@fcwilt The problem with conditionally defining local variables is:

"The scope of a local name is the remainder of the block in which it is declared."

So, this will produce "unknown variable":
if !exists(var.xxx)
	var xxx=0
set var.xxx=4
I'm trying to think of a workaround I can use right now, besides just making them globals.

Well that is not good news.

This my be a problem only @dc42 can solve.

Frederick

DonStauffer

@fcwilt I've just been doing an M999 between jobs for now.