Posts made by cheeseandham

@droftarts said in Bug:Object model discrepancies:

wondered if you were still running a mirror of the old RRP instructions!

Adrian did eventually host a copy on RepRapLtd, so my mirror was not so important (Although photos do not "expand" on his copy) The domain expired, although the website is still "live" on my hosting, but I was thinking the other day whether to buy the domain again (it's a uk domain so pretty cheap)

@droftarts said in Bug:Object model discrepancies:

try using userPosition rather than machinePosition.

I didn't notice that object, and that's fixed the problem.
Apologies for reporting as a "bug" prematurely. I'll be more careful about that in future!
I guess I just need to scale my M208 to compensate for axis scaling, and everything is fine.
Solved!

Hey @droftarts!
On a personal note, nice to see you back around the RRF community! I remember you well, from the Reprap forums and back when I had to come to RepRapPro shed twice with my Ormerod2

Aha! Interesting! I'll happily get rid of my axes scaling for now as it doesn't really affect me that much.
However as I'd like the script I'm developing to be applied across other printers in my printers community, my questions are:

i) Is there an object model model reading of M114? Or do I have to "process" it with my axis scaling?
ii) Is the application of the scaled value to M208 (thereby in my case, not allowing you to reach the value stated) intentional/wanted behaviour?

Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.2-beta1 (2020-09-15b1)
Duet WiFi Server Version: 1.23

Config.g - https://github.com/dandancheeseandham/cheeseandham-railcore/blob/master/RRF3.1/sys/config.g

Steps to reproduce bug:

1. Go to any larger non-zero XY position. e.g.
   G1 X100 Y100
   G1 X150 Y200
   G1 X300 Y300

2. Confirm position with M114 and DWC

3. Compare against output of

echo "current machine position",{move.axes[0].machinePosition},{move.axes[1].machinePosition},{move.axes[2].machinePosition}

Object model is out on my machine by 0.27 every 100mm (so at position 300 on X or Y the position is reported as 300.810)

Additional: Axis limits via M208 seem to adhere to object model, so if I set max Y to 300 I can only go to 299.2 according to DWC/M114.
However if I set Y limit to 300.810 such as

M208 X-10:305 Y0:300.810 Z0:610

then I can go to Y300 (as read by DWC/M114) and the object model reads 300.810

I've just realised, I just need to wait for variables...

Use object model to get value and assign to variable. Make changes/run script, and then use variable to assign the previous values.

Nothing to see here! As you were!

I came here to ask for the same feature, although where I'm coming from is to really aid the transportability of scripts, and allowing them to be "future-proofed" against changes to your configuration.

For example, if I write a script which required changing the M558 A value to 5 for the duration of the script, currently I cannot reset it back to whatever the user had before at the end.
If it was possible to push any object or value previously set, I could push that existing value onto a stack, make my changes (i.e. change M558 A to 5) and then pop it back when finished.

For my own scripts, this is not an issue as I know what values I have set, but to be able to disseminate scripts to a community can be tricky - I may have no idea of what someone else's values are initially set at, and either have to write comments for people to change and keep updates in the script, or go for a logical/probable value within the community of my 3D printer.

"Future-proofing" is similar, perhaps my script changes my maximum jerk and accel for the duration of the script and resets to my (current) values at the end. If I modify my config.g values at a later date, I need to update any scripts that "change and set back" these values.

(loving RRF3 on the Duet2 BTW!)

Great news. Thanks dc42!

I don't know if this is useful additional information but I asked someone with Duet Ethernet 1.02 or later + DueX5 and RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-RC1 (2020-02-08b3) to run

echo "fans[0].name :",fans[0].name
echo "fans[1].name :",fans[1].name
echo "fans[2].name :",fans[2].name
echo "fans[3].name :",fans[3].name
echo "fans[4].name :",fans[4].name
echo "fans[5].name :",fans[5].name
echo "fans[6].name :",fans[6].name
echo "fans[7].name :",fans[7].name
echo "fans[8].name :",fans[8].name

They reported that they got "Error: in file macro, line 7 column 23: array index out of bounds"

I've been investigating the object model and found that the following script resets my Duet.

Board: Duet WiFi 1.02 or later + DueX5
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-RC3 (2020-02-29b4)
Duet WiFi Server Version: 1.23

(also tested on Duet 2 3.01 RC1 and RC2)

echo "fans[0].name :",fans[0].name
echo "fans[1].name :",fans[1].name
echo "fans[2].name :",fans[2].name
echo "fans[3].name :",fans[3].name

M122 report is

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.01-RC3 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-95BLL-N6PSS-6JKD2-3SJ6M-10UMJ
Used output buffers: 3 of 24 (14 max)
=== RTOS ===
Static ram: 27916
Dynamic ram: 93976 of which 44 recycled
Exception stack ram used: 272
Never used ram: 8864
Tasks: NETWORK(ready,732) HEAT(blocked,1240) DUEX(suspended,136) MAIN(running,1924) IDLE(ready,76)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:00:36 ago, cause: software
Last software reset at 2020-02-29 22:51, reason: Hard fault, spinning module GCodes, available RAM 8536 bytes (slot 3)
Software reset code 0x0063 HFSR 0x40000000 CFSR 0x00000001 ICSR 0x0041f803 BFAR 0xe000ed38 SP 0x20004f04 Task 0x4e49414d
Stack: 004043f7 b2c96804 000f0000 00000000 a5a5a5a5 200051b8 0042cad9 00000001 20001408 00000001 00000000 
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 3.3ms, max retries 0
MCU temperature: min 41.1, current 42.5, max 43.1
Supply voltage: min 23.9, current 24.1, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-02-29 22:52:02
Cache data hit count 64014950
Slowest loop: 46.43ms; fastest: 0.12ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 168, MaxWait: 546ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 1, completed moves: 1, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== 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
serial 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
daemon is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 81.29ms; fastest: 0.00ms
Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
- WiFi -
Network state is running
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 2c:3a:e8:0b:09:f7
WiFi Vcc 3.41, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24080
WiFi IP address 192.168.0.26
WiFi signal strength -51dBm, reconnections 0, sleep mode modem
Socket states: 4 0 0 0 0 0 0 0

M409 K"fans" is

{"key":"fans","flags":"","result":[{"actualValue":0,"blip":0.10,"max":1.00,"min":0.10,"name":"","requestedValue":0,"rpm":-1,"thermostatic":{"control":false}},{"actualValue":0,"blip":0.10,"max":1.00,"min":0.10,"name":"","requestedValue":0,"rpm":-1,"thermostatic":{"control":false}},{"actualValue":0,"blip":0.10,"max":1.00,"min":0.10,"name":"Part","requestedValue":0,"rpm":-1,"thermostatic":{"control":false}},null,null,null,{"actualValue":0,"blip":0.10,"max":1.00,"min":0.10,"name":"Hotend","requestedValue":1.00,"rpm":-1,"thermostatic":{"control":true,"heaters":[1],"highTemperature":45.0,"lowTemperature":45.0}},{"actualValue":0.38,"blip":0.10,"max":1.00,"min":0.10,"name":"Elec.Cab.1","requestedValue":1.00,"rpm":-1,"thermostatic":{"control":true,"heaters":[10],"highTemperature":55.0,"lowTemperature":35.0}},{"actualValue":0.38,"blip":0.10,"max":1.00,"min":0.10,"name":"Elec.Cab.2","requestedValue":1.00,"rpm":-1,"thermostatic":{"control":true,"heaters":[10],"highTemperature":55.0,"lowTemperature":35.0}}]}

Confirmed working, but as an addendum to anyone reading this , this does require RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta1+1 (2020-01-15b2)

RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta1 (2020-01-14b3) gives "unknown value initialDeviation.deviation" errors.

Thanks dc42

(Just so there is no misunderstanding, I'm swearing at myself for being so utterly stupid, and I really appreciate your reply and assistance @deckingman )

@deckingman
I just swore out loud there. I could've sworn I'd tested that.
I'm an idiot. Thank you.

SOLVED

1_1563269727726_config-user.g
0_1563269727726_config.g

(removed text config-user.g)

(removed text version of config.g)

Versions of things:

• Duet 2 WiFi H/W v1.03 F/W:Duet 2 WiFi/Ethernet 2.04RC1 (2019-07-14b1)
• Duet WiFi Server Version: 1.23
• DueX5 (H/W V0.9a)
• Duet Web Control 2.0.0-RC6

**Problem: **

My fan is supposed to be remapped to fan 2. It has worked in the past.

Executing

M106 P2 Sxxx

Switches the fan on and off depending on the S value

However

M106 Sxxx

does nothing, which is a problem with my slicer.

Aat some point it appears to have stopped working (2.03 appeared not to work either)

M563 P0 and M106 P2 reports

16/07/2019, 10:22:34: M563 P0: Tool 0 - name: E3Dv6 Gold; drives: 0; heaters (active/standby temps): 1 (-273.1/-273.1); xmap: X; ymap: Y; fans: 2; status: off
16/07/2019, 10:25:48: M106 P2: Fan 2 (Part) pin: F2, frequency: 250Hz, speed: 100%, min: 10%, max: 100%, blip: 0.10, inverted: no

What am I doing something wrong here please?

I'm using M915 P0:1 S3 R0 F0 for sensorless homing on X & Y quite happily here. Have done since my RailCore II was built.

I've a head crash recently, and was due to wiring fault. (what was thought was a well fastened cable coming off my mini-differential IR probe)

My approach was to try M915 P5:6:7 S3 R3 F0with a rehome.g file. The rehome.g called M112 and M999 in order to just stop the printer dead in it's tracks.

Homed my printer and then manually held down the bed , stalling the motors plenty - to no effect.

David,

Thank you for your advice!

I double checked the power, re-seated everything again and examined and re-seated the ribbon cable.

When I turned back on it worked, so it was definitely one of these things. Apologies for not testing individually Solved!

Are you sure it's not reporting the same error on driver 9 too?

It didn't report driver 9 , as you can see in the original screenshots - possibly because my config.g doesn't reference it?)

Versions of things:

• Duet 2 WiFi H/W v1.03 F/W: 2.03beta3 (2019-03-25b6)
• Duet WiFi Server Version: 1.23
• DueX5 (H/W V0.9a)
• Duet Web Control 2.0.0-RC6

An RS Components Mean Well ERPF-400-24, wired up to an older Duet 2 Wifi 1.03 and a new Duex5 V0.9a (both purchased from Think3DPrint3D) and commissioning a CoreXY (RailCore II 300ZLT)

Wiring - pic.
Duet and Duex5 are mounted on nylon inserts and is clear underneath - pic

Hooked via USB, web interface and system responds normally.
I've used the stock github config.g and the Project R3D kit config which I know more people have used and is very similar bar the way the steppers move forwards and backwards.

The Problem: When plugged in with nothing but power into the Duet & Duex5 as shown, the Duet powers up and I can access the web interface, but I get the following errors constantly

"Error: short-to-ground reported by driver(s) 5 6 7 8" and
"Error: over temperature shutdown reported by driver(s) 5 6 7 8" - pic

I've examined the back of the board, I can see no obvious signs of damage or misplaced solder.

Your thoughts and input are appreciated.

@supraguy said in To retrofit, or not to retrofit...:

Leave it be, and connect one of my many Raspberry Pi SBCs to it to give it WiFi connectivity.

I love the Duet boards and have had many, however I am also a proponent of "if it ain't broke, don't fix it" and I would go with this option, add a RPi to the clone , and make a start on the Railcore-like project (or use the Duet for the CNC

OK, so in this new firmware tool, bed.g now calls G29 for mesh bed compensation, and doesn't allow you to set probe points.

So we can't use this new tool for setting bed.g with Bed levelling using multiple independent Z motors as we could with the v1 tool.

Not a complaint, just an observation , as I guess this setup is in the minority.

Thanks for updating it Chris.