Topics created by DonStauffer

@DonStauffer You could connect via USB while the printer is running, and turn the WiFi off and on with M552 S-1 then M552 S1. Otherwise I think it will be fine to leave it until the print finishes.

Ian

Wattage is the result of voltage and current. The lower voltage heating rate would be more affected by the cooling rate of heat dissapating into the air, which is more easily overcome by the higher voltage.

@dc42 The Adafruit documentation is ambiguous because it's internally contradictory by one byte. So I don't know.

@DonStauffer probably the work noted at https://github.com/Duet3D/RepRapFirmware/blob/bd8d9119d49ba425864f2280b005875b368746c0/src/Todo-next.txt#L25

@DonStauffer I went up to 9000, and it seems fine, and faster.

@infiniteloop It was specifically how the GCode part of it interacted that I didn't understand. The HRP is explained, and the GCodes are named, but how they interact seems to be a weak point of the docs.

Thanks you, everyone! It's been very helpful and I think I have it worked out now.

So here's the end result, in case it helps any future enthusiast to have an example:
Bed.png
The measurements I used in this discussion were rounded versions of my real machine to make it easy to talk about; this image contains the real values. Here's the actual geometry and what I settled on for settings. I left M208 X0 Y0 and used the probe as HRP, which simplifies the probing issue, and using the primary nozzle seems like it complicates and confuses things when using the secondary. In theory, my 2 nozzles and probe are supposed to all have the same X coordinate, but I had to fine tune it so the 2 nozzles come out in the same place given the same G0 or G1 command, and in real life they aren't quite in a line.

Regarding bed leveling, it's my understanding that the probe points need not all be in exactly the same relation to their respective screws as one another - that the differences are compensated for in the math. I did the best I could on each one, but naturally the machine home prevents getting toward the front enough to be close to the front left probe point. and the fans are in the way on the right probe point. My leveling isn't actually all that repeatable, but I'm assuming that's my build material not being held down well enough (PEI 2mm).

@DonStauffer yes the memory allocated for var.A will be made available for use by other variables when it goes out of scope.

@DonStauffer I have now reproduced this and created https://github.com/Duet3D/RepRapFirmware/issues/1020 and https://github.com/Duet3D/RepRapFirmware/issues/1021.

dc42 created this issue in Duet3D/RepRapFirmware closed Incorrect processing of # operator when operand is an element of an array of arrays #1020 dc42 created this issue in Duet3D/RepRapFirmware closed Parsing error when using ternary operator #1021

@dc42 Both of these produce errors.

;exists(#var.x) ;exists(var.x[0]) var x = {1,2} var y = 3 ; Method 1 if exists(#var.x) ; expected an identifier echo "exists(#var.x)" else echo "! exists(#var.x)" if exists(#var.y) echo "exists(#var.y)" else echo "! exists(#var.y)" ; Method 2 if exists(var.x[0]) echo "exists(var.x[0])" else echo "! exists(var.x[0])" if exists(var.y[0]) ; Cannot index into variable or parameter 'y^' of non-array type echo "exists(var.y[0])" else echo "! exists(var.y[0])"

@DonStauffer I think there's enough drivers and I/O on a Duet 3 Mini 5+ with Duet 3 expansion Mini 2+ (to give 7 motor drivers) to drive your setup.

Ian

@DonStauffer I'd suggest that you move the BLTouch reset to be after you have lowered the bed (that way if part of the reset involves any sort of probe deployment it should be safe). I'd also suggest that you lower the motor current when performing the probe, just in case something goes wrong with the probe.

@dc42 I can work around it. It just took me a while to figure out what was happening. I ended up with 2 tools heating at the same time unexpectedly.

@DonStauffer tools[].axes[] has a bitmap type in the OM, which is essentially a set of values all of which lie within a certain range. RRF meta GCode doesn't really support set types, but in order to allow you to delve into it, RRF lets you use the # operator on it (to ask how many bits are set) and to use the [] indexing operator to retrieve the bit numbers in ascending order.

@dc42 I suspect it was just running out of memory, but I haven't tried this particular construct again with more free memory. I'll try it tomorrow.

@dc42 I got rid of about half my array elements by restructuring it, and for the first time, 100% of the reboots stopped. So fundamentally, it seems like I have between 1kB and 1.5kB of global space to play with total, or else I start getting a mess. In other words, I was running out of memory, but instead of sending a message, it slammed into a brick wall. So all the other stuff was probably just rearranging where and when the memory ran out.

@droftarts OK, it's not a bug, it's a feature! 🙂

@DonStauffer I think you should post your config.g bed.g and homez.g files

You might also want to try running some tests to see how repeatable the results are from your z probe. That test can also be used to help you decide what acceleration and dive speed.

The purpose of that final probe is to reset your Z=0 (though I'm not sure what that G30 X150 Y150 Z-99999 will actually be doing, I suspect it may just be storing the value in p0, but I may be wrong). The normal way to do this would either be to run G28 Z or to position the probe and run just a plain G30. You need to do this because the adjustments made to level the bed will mean that Z=0 is no longer valid.

@dc42 I was able to free up 112 integers from one of the global arrays by combining RGB values into single integers. The spontaneous rebooting stopped as far as I can tell. Through it all I've never again seen the array corruption, so I'm confident your fix solved that. Things are running fine now. Thanks for everything!

@DonStauffer thanks for reporting this. It's not intended behaviour. I have created https://github.com/Duet3D/RepRapFirmware/issues/1003.

dc42 created this issue in Duet3D/RepRapFirmware closed Bug: can't create a variable with the same name as a parameter #1003