Cannot understand web page for Machine Properties
-
@deckingman said in Cannot understand web page for Machine Properties:
Yes, I have exactly the same. E0 and E1 have the speed, acceleration and current values associated with the U and V axes (which aren't shown at all).
EDIT. That's with Chris Ham's 1.22 final.
Glad to see it verified. Sometimes I think I'm the only one who has these issues.
Frederick
-
DC42:
DWC (latest release) is looking for JSON keys minFeedrates, maxFeedrates, and accelerations to populate the rows that are wrong in some people's Machine Properties.
Keeping in mind that DWC sort of "merges" JSON responses and the things that it saves across sessions, andc complicating things further, DWC used to save things to browser local storage and now saves them to a file in /sys on the Duet to which it is connected at that moment... I speculate that old information in the session store is the ONLY reason anyone's rows are correct. (I have not exhaustively researched this).
Anyway, minFeedrates, maxfeedrates, and accelerations DO NOT occur in any of the (current release) RepRap responses to RR_STATUS. None of Type 1, 2, or 3 (which are the only three DWC ever calls) return these keys.
M408 S5 uses "getConfigResponse" buffer layout for S5, and this DOES contain these keys.
I speculate that the other buffer layouts, the buffers GetLegacyStatusResponse and/or GetStatusResponse, the buffer layouts that are used for both RR_STATUS and various M408 S1 through S4, might have contained these keys in the past. I'm not quite a github wizard enough to prove that either way. Most likely the GetStatusResponse as it is used for both M408 S2 and RR_STATUS,TYPE=2.
At any rate, to summarize:
-
I am 100% certain that DWC is looking for keys that are not sent in any RR_STATUS 1, 2, or 3.
-
I am 99% certain that these keys were in GetStatusResponse buffer at some point in the past.
-
I am 60% certain that DWC is keeping past information in its session store, making this breakdown in communication very difficult to detect in regression testing of new releases.
P.S. Might I offer that the "test suite" for regression testing should include deleting DWC session store prior to connecting to a Duet for DWC validation?
-
-
What I think is happening is that the Machine Properties data includes data for all axes, but DWC doesn't know about hidden axes. So if you have any hidden axes, there are rows for them in Machine Properties, but they are labelled as extruders.
-
@danal said in Cannot understand web page for Machine Properties:
Anyway, minFeedrates, maxfeedrates, and accelerations DO NOT occur in any of the (current release) RepRap responses to RR_STATUS. None of Type 1, 2, or 3 (which are the only three DWC ever calls) return these keys.
These values are contained in
http://.../rr_config
{ "axisMins": [ -32.5, -1.5, 0.0 ], "axisMaxes": [ 220.0, 230.0, 220.0 ], "accelerations": [ 2000.0, 2000.0, 100.0, 10000.0, 10000.0, 250.0, 250.0, 250.0, 250.0, 250.0, 250.0, 250.0 ], "currents": [ 500.0, 500.0, 500.0, 700.0, 700.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ], "firmwareElectronics": "Duet WiFi 1.02 or later", "firmwareName": "RepRapFirmware for Duet 2 WiFi/Ethernet", "firmwareVersion": "2.01(RTOS)", "dwsVersion": "1.21", "firmwareDate": "2018-07-26b2", "idleCurrentFactor": 30.0, "idleTimeout": 15.0, "minFeedrates": [ 10.0, 10.0, 0.4, 5.0, 5.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0 ], "maxFeedrates": [ 110.0, 110.0, 12.0, 50.0, 50.0, 20.0, 20.0, 20.0, 20.0, 20.0, 20.0, 20.0 ] }
-
@dc42 said in Cannot understand web page for Machine Properties:
What I think is happening is that the Machine Properties data includes data for all axes, but DWC doesn't know about hidden axes. So if you have any hidden axes, there are rows for them in Machine Properties, but they are labelled as extruders.
That would appear to be the case.
It's not a big deal but if possible I think DWC should be updated to handle the additional axes.
Thanks.
Frederick
-
Added to the list.
-
AHA, I was down a rabbit hole. Forgot about RR_CONFIG.
Doh !
-
Doesn't seem to have anything to do with being hidden (M584 P being less than total).
It appears that any extra axis will throw off DWC as currently coded.Within DWC, there is a semi-hard-coded "maxAxis" of 12. This corresponds to a 12 row (not counting title row) 'machine properties' table in the HTML. The code that populates that 'machine properties' table always loops 12 times, so it can hide/unhide rows as appropriate. Also, it is pulling various keys out of the response to RR_CONFIG and putting them in the unhidden rows. So far, so good.
Within that loop, there is ALSO an 'if' that decides whether a given row is hidden/unhidden. It does so by taking keys from a regular RR_STATUS type 1, 2, , or 3, whatever was most recent, where the coords.xyz.length + coords.extr.length being less than the loop count is the actual 'if'.
A mathematical sum is not sufficient to determine which axis is which type. That's why DWC is treating any extra axis as extra extruders.
The DWC code needs to parse whatever is in coords.xyz array as X, Y, Z, U', V, etc. and the parse coords.extr as E0, E1, etc.
-
Quick experiments, showing only a subset of the relevant keys from each response.
M584 X0 Y1 Z2 E3
(i.e. same as default if not coded)RR_CONFIG "axisMins":[-304.00,-304.00,0.00]
RR_STATUS "status":"I","coords":{"axesHomed":[0,0,0],"xyz":[0.000,0.000,626.751],"machine":[0.000,0.000,626.751],"extr":[0.0]},
Machine Control Page: Correct.
Machine Properties Table: Correct..
M584 X0 Y1 Z2 E3 U7 V8
RR_CONFIG "axisMins":[-304.00,-304.00,0.00,0.00,0.00]
RR_STATUS "xyz":[0.000,0.000,626.751,0.000,0.000],"machine":[0.000,0.000,626.751,0.000,0.000],"extr":[0.0]}
Machine control page: Correct.
Machine Properties Table: Incorrect. Shows 3 extruders. The "last one" is the actual extruder; the first two are really U and V -
And... if the config "skips" an axis, I'm not sure there is enough info in RR_CONFIG for any possible parser to discern that:
M584 X0 Y1 Z2 E3 V8 {"axisMins":[-304.00,-304.00,0.00,0.00], "axisMaxes":[304.00,304.00,627.01,0.00], "accelerations":[4000.00,4000.00,4000.00,250.00,2000.00,250.00,250.00,250.00,250.00,250.00,250.00,250.00], "currents":[1200.00,1200.00,1200.00,0.00,1800.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00], "firmwareElectronics":"Duet WiFi 1.02 or later","firmwareName":"RepRapFirmware for Duet 2 WiFi/Ethernet", "firmwareVersion":"2.01(RTOS)","dwsVersion":"1.21", "firmwareDate":"2018-07-26b2", "idleCurrentFactor":30.0, "idleTimeout":30.0, "minFeedrates":[20.00,20.00,20.00,2.00,20.00,2.00,2.00,2.00,2.00,2.00,2.00,2.00], "maxFeedrates":[300.00,300.00,300.00,20.00,20.00,20.00,20.00,20.00,20.00,20.00,20.00,20.00]}
Machine control page: Incorrect. Shows 'V' instead of 'U'.
Machine Properties Table: Incorrect. Shows 2 extruders. The "last one" is the actual extruder; the first one is really V. -
Thanks for your research. Let's see what chrishamm says.
-
Hi,
Good work.
You have demonstrated one of the shortcomings of an list of unnamed values. Unless the ordering in the list never changes and includes a location for each possible value source it can be hard to analyze.
One of the reasons I prefer to use a simplified form of XML for this sort of thing - all values are named.
That's a discussion for another time and place.
Thanks.
Frederick
-
At the moment DWC displays only the first n drives where n is the sum of visible axes and configured extruders. I agree there is a problem with that for more sophisticated machine setups, e.g. where axes are hidden or assigned to multiple drives.
@dc42 Do you think we should add a bitmap to the config response which indicates which drives are actually in use? This would probably make more sense than the current approach. Also, it may make sense to include another field so that DWC can display which drive is assigned to what axis/extruder.
-
@chrishamm said in Cannot understand web page for Machine Properties:
At the moment DWC displays only the first n drives where n is the sum of visible axes and configured extruders. I agree there is a problem with that for more sophisticated machine setups, e.g. where axes are hidden or assigned to multiple drives.
Thanks for considering the issue.
Frederick