RepRapFirmware 3.01beta1 released

DIY-O-Sphere

@dc42
Hi David, maybe I have found a bug....
For testing I was back on 2.05 on a Maestro (DWC 2.06) and I was not able to get back directly to 3.01b.
Flashing 3.0 stable worked.

dc42

@DIY-O-Sphere said in RepRapFirmware 3.01beta1 released:

For testing I was back on 2.05 on a Maestro (DWC 2.06) and I was not able to get back directly to 3.01b.

Read the upgrade notes!

gtj0

@dc42 said in RepRapFirmware 3.01beta1 released:

Thanks for confirming. FWIW, maximum GCode line length excluding leading white space, line number and checksum (if present) and comments is currently 160 characters.

Are you sending them via text message???

DIY-O-Sphere

@dc42 said in RepRapFirmware 3.01beta1 released:

Read the upgrade notes!

Sorry....The one who can read is in advantage

dc42

@gtj0 said in RepRapFirmware 3.01beta1 released:

@dc42 said in RepRapFirmware 3.01beta1 released:

Thanks for confirming. FWIW, maximum GCode line length excluding leading white space, line number and checksum (if present) and comments is currently 160 characters.

Are you sending them via text message???

Hadn't you noticed your smartphone bills going up every time you print?

gtj0

@dc42 said in RepRapFirmware 3.01beta1 released:

@gtj0 said in RepRapFirmware 3.01beta1 released:

@dc42 said in RepRapFirmware 3.01beta1 released:

Thanks for confirming. FWIW, maximum GCode line length excluding leading white space, line number and checksum (if present) and comments is currently 160 characters.

Are you sending them via text message???

Hadn't you noticed your smartphone bills going up every time you print?

Ah that makes sense now. I though it was the cat texting his buddy across the street.

garyd9

@kraegar said in RepRapFirmware 3.01beta1 released:

Here is the version that works well:

I like this, but it seems unnatural to have to repeat the same G30 commands twice in the same script. This is more significant with a delta printer (that often has many more probe points.)

I'm wondering what alternatives might exist. I see there's no do/while (which would be my first thought), but I'm wondering if it would work to put the list of G30 gcodes in a different file (bed-probes.g)

@dc42, do the variables from the object model available survive across different scripts? For example, if I had file called "bed-ProbePoints.g" that contained something like:

G30 P0 Xn Yn 
...
G30 P18 X0 Y0 S6

And then my bed.g contained:

M561
G28
M98 P"bed-ProbePoints.g" 
while true
    if iterations > 5
        abort "something needs tightening..."
    if abs(move.initialDeviation.deviation - move.calibrationDeviation.deviation) <= 0.01
       break
    M98 P"bed-ProbePoints.g"

Would this work? Would the deviation values be updated across the scripts?

Thank you
Gary

kraegar

@garyd9 This was my very rough first iteration (and still is early, room for improvement, etc etc). Only posted in this thread due to the bugs I was noticing.

Anyway, see my post here where I did split the G30 segment out into a macro:
https://forum.duet3d.com/topic/13890/auto-tramming-a-railcore-using-conditional-gcode

garyd9

@kraegar That is great (and answers my question.)

thank you

insertnamehere

@dc42 said in RepRapFirmware 3.01beta1 released:

You've found a bug (the property table wasn't ordered alphabetically after I renamed a property, so the binary search failed). I've fixed it in the latest build at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. I also added a compile-time check to prevent this happening in future, and an extra property state.upTime.

Firstly, thanks for the quick response. I've tried the fixed firmware and it works great.

Another thing, I use an ATX type 24V supply controlled by the PS_ON pin.
After all axis are homed, if I turn of the 24V supply, the axis remain homed "Blue" on the DWC. If I turn on the ATX supply again I can move all axis as if they are homed. Shouldn't turning of the 24V supply automatically mark all axis as homed : false?

m409
{"key":"","flags":"","result":{"boards":[{"firmwareFileName":"Duet2CombinedFirmware.bin","firmwareVersion":"3.01-beta1+1","iapFileNameSD":"Duet2CombinedIAP.bin","mcuTemp":{"current":39.6,"max":39.9,"min":38.0},"name":"Duet 2 WiFi","shortName":"2WiFi","vIn":{"current":0.7,"max":24.4,"min":0.4}}],"heat":{"coldExtrudeTemperature":160.0,"coldRetractTemperature":90.0,"heaters":[{"current":22.0,"sensor":0,"state":"Off"},{"current":23.2,"sensor":1,"state":"Active"}],"sensors":[{"lastReading":22.0,"name":"","type":"Thermistor"},{"lastReading":23.2,"name":"","type":"Thermistor"}]},"job":{"file":{"filament":[],"firstLayerHeight":0.0,"generatedBy":"","height":0.0,"lastModified":"28115-10-29T03:41:51","layerHeight":0.0,"numLayers":0,"printTime":0,"simulatedTime":0,"size":0},"lastFileName":"","layer":0,"timesLeft":{"filament":0.0,"file":0.0,"layer":0.0}},"move":{"axes":[{"homed":true,"letter":"X","max":300.0,"min":0.0,"userPosition":70.000,"visible":true},{"homed":true,"letter":"Y","max":300.0,"min":0.0,"userPosition":265.000,"visible":true},{"homed":true,"letter":"Z","max":350.0,"min":0.0,"userPosition":4.213,"visible":true}],"calibrationDeviation":{"deviation":0.000,"mean":0.000},"currentMove":{"requestedSpeed":0.0,"topSpeed":0.0},"daa":{"enabled":false,"minimumAcceleration":10.0,"period":0.0},"idle":{"factor":0.7,"timeout":30000},"initialDeviation":{"deviation":0.004,"mean":0.014},"meshDeviation":{"deviation":0.032,"mean":0.099},"printingAcceleration":10000.0,"speedFactor":100.0,"travelAcceleration":10000.0},"network":{"interfaces":[{"actualIP":"192.168.1.142","firmwareVersion":null,"gateway":"0.0.0.0","subnet":"0.255.255.255","type":"wifi"}]},"state":{"currentTool":0,"machineMode":"FFF","status":"Off","upTime":193}}}

dc42

@insertnamehere said in RepRapFirmware 3.01beta1 released:

After all axis are homed, if I turn of the 24V supply, the axis remain homed "Blue" on the DWC. If I turn on the ATX supply again I can move all axis as if they are homed. Shouldn't turning of the 24V supply automatically mark all axis as homed : false?

Yes. I will fix that.

garyd9

@dc42
With the build from your dropbox...

Error: in file macro, line 18 column 12: unknown value abs

The line in question:

if abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.02

dc42

@garyd9, try enclosing the whole expression in { } so that the round brackets are not treated as enclosing comments.

The deviation value is RMS so it is always positive, unlike the mean.

dc42

I've just put 3.01-beta1+1 (2020-01-17b3) binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. These support additional OM variables, including extruder parameters such as pressure advance.

The format for driver IDs may change in future beta releases. I am currently returning strings such as "3.1" for driver 1 on board 3; but I may change this to return 301 in this case, i.e. 100*board_id + driver_number. Whichever I choose, I will allow the format returned by the OM variable to be used in M584, M569 etc.

Danal

@dc42 said in RepRapFirmware 3.01beta1 released:

but I may change this

If you are taking votes/opinions, overall compatibility with the pin labeling nomenclature seems desirable.

garyd9

@dc42 said in RepRapFirmware 3.01beta1 released:

@garyd9, try enclosing the whole expression in { } so that the round brackets are not treated as enclosing comments.

The deviation value is RMS so it is always positive, unlike the mean.

About being positive, that's true, but the difference between means might be negative, so I want to get the absolute value of the difference...

As for using curly braces, I'm not having much luck with that. Perhaps because I'm not quite sure where, exactly, the curly braces should be. Here's some of the things I tried, followed by the resulting error:

if {abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}
Error: in file macro, line 16 column 91: expected ')'

if abs{(move.calibrationDeviation.deviation - move.initialDeviation.deviation)} < 0.002
Error: in file macro, line 16 column 11: unknown value abs

if abs{move.calibrationDeviation.deviation - move.initialDeviation.deviation} < 0.002
Error: in file macro, line 16 column 11: unknown value abs

if abs({move.calibrationDeviation.deviation - move.initialDeviation.deviation}) < 0.002
Error: in file macro, line 16 column 12: unknown value abs

{if abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}
Error: Bad command: {if abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}

To be absolutely clear, my intention is to get the absolute value of the difference of the two deviations, and compare that to 0.002

Danal

@garyd9 said in RepRapFirmware 3.01beta1 released:

if {abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}

I get no error with the format above. Running:

Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.01-beta1+1 (2020-01-17b3)

garyd9

@Danal said in RepRapFirmware 3.01beta1 released:

@garyd9 said in RepRapFirmware 3.01beta1 released:

if {abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}

I get no error with the format above. Running:

Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.01-beta1+1 (2020-01-17b3)

Odd. I'm also running "3.01-beta1+1 (2020-01-17b3)". Perhaps because I'm running it on a Duet2 (duet wifi)?

I'll try again in 5-6 hours (if I'm still awake) when my current print finishes...

I will say that I'm starting to wonder if I should "upgrade" to a duet3. While I really don't need the extra ports or capabilities, the newer versions of RRF3 seem to bog down the older boards. I started to get hiccups on my delta at even only 150mm/sec movements now.

Danal

Yeah, and I'm running a Pi. It is very unclear to me how much gcode is processed on the DSF on the Pi vs actually being passed to the Duet.

dc42

@Danal said in RepRapFirmware 3.01beta1 released:

Yeah, and I'm running a Pi. It is very unclear to me how much gcode is processed on the DSF on the Pi vs actually being passed to the Duet.

GCodes commands are pre-parsed on the Pi, but most of them are just passed in the parsed state to the Duet. A few such as M98 and M32 are processed partly on the Pi.

I am currently looking at the why RRF3 has hiccups at lower step rates than RRF2.