If I work on the heater model, where would you like it?
-
@dc42 If you're not already working on it, I can get the heater model added to the status reponse. The question is...where do you want it? I was thinking of adding a type "6" but should that be a stand alone dump of just the heater models or should it be the output of an existing type + heater models?
-
see this for contribution
https://duet3d.dozuki.com/Wiki/Contributing_to_firmware_development -
We are trying to avoid adding more data to the status response, because the plan is to provide a much more general mechanism to retrieve parts of the object model. The proof-of-concept code is already in RRF, for example if you send:
M408 P1 F"network.interfaces"then it will return that part of the object model as a JSON object. It's not fully working yet for several reasons. Command:
M408 P1 F"network.interfaces[0]"should return the first element of the interfaces array, but doesn't. But the main reason is that only a tiny part of the object model is accessible in RRF at present, and it needs to be refactored to match the object model described at https://chrishamm.github.io/DuetSoftwareFramework/html/G_DuetAPI.htm. So the way to retrieve a heater model will be to use a command like this:
M408 P1 F"Machine.Heat.Heaters[0].Model"Currently the Heat class in RRF doesn't have an object model, but it would be easy to add one using the same pattern as for other classes (e.g. Network and GCodes). Please note, the object model tables are constructed so as to use no RAM. This is essential so that the object mode can be implemented on Duet 2, which doesn't have much spare RAM.
-
@gtj0, your post inspired me to look at the object model work again. In RRF3 I have now added a basic object model to class Heat and fixed the issue with indexing. However, to access heater objects safely in the OM it will be necessary to extend the OM type system to handle arrays of read locked pointers to objects (currently it only handles arrays of void* pointers). So that's the next task on the way to making heater models and other heater properties generally available.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 @chrishamm would you guys entertain changes to the heat model?
- Remove bed and chamber arrays
- Add all heaters to the "heaters" array with a "function_type" parameter...
- 0: Bed
- 1: Tool
- 2: Chamber
- 3: Other
- Add "function_index" parameter (which bed, chamber, tool, etc)
- Add "active" and "standby" parameters to "heaters" (for a tool heater, they'd be the currently effective values.
- Remove "current" from "heater" (get it from the sensor)
- Move "extra" to "sensors" as "thermal"
From heater you can now easily find tool and sensor.
From sensor you can easily find heater.
From tools you can already find heaters."heat" : { "coldExtrudeTemperature" : 160, "coldRetractTemperature" : 90, "heaters" : [ { "effective_active": 70, "effective_standby": 55, "logical_index": 0, "logical_type": 0, "max" : 290, "model" : { "customPID" : false, "d" : 0, "deadTime" : null, "gain" : null, "i" : 0, "maxPwm" : null, "p" : 0, "standardVoltage" : null, "timeConstant" : null, "usePID" : true }, "name" : "Bed", "thermal_sensor" : 0, "state" : 0 }, { "effective_active": 225, "effective_standby": 160, "logical_index": 0, "logical_type": 1, "max" : 290, "model" : { "customPID" : false, "d" : 0, "deadTime" : null, "gain" : null, "i" : 0, "maxPwm" : null, "p" : 0, "standardVoltage" : null, "timeConstant" : null, "usePID" : true }, "name" : "HotEnd", "thermal_sensor" : 1, "state" : 0 } ] }, "sensors" : { "endstops" : [ ], "thermal" : [ { "current" : 20.1, "heater": 0, "name" : "Bed", "sensor" : null, "state" : null }, { "current" : 19.1, "heater": 1, "name" : "HotEnd", "sensor" : null, "state" : null }, { "current" : 19.7, "heater": -1, "name" : "Bed Check", "sensor" : null, "state" : null }, { "current" : 13.8, "heater": -1, "name" : "Ambient", "sensor" : null, "state" : null } ] } -
@dc42 said in If I work on the heater model, where would you like it?:
@gtj0, your post inspired me to look at the object model work again. In RRF3 I have now added a basic object model to class Heat and fixed the issue with indexing. However, to access heater objects safely in the OM it will be necessary to extend the OM type system to handle arrays of read locked pointers to objects (currently it only handles arrays of void* pointers). So that's the next task on the way to making heater models and other heater properties generally available.
OK, I think I'd better leave that to you then. The chances of me getting that the way you want it are pretty slim.
-
@gtj0, as a model for the whole heat subsystem (as returned by M408 P1 F"Heat") your model looks OK to me, although the field names are not in accordance with the naming convention used in the DSF object model. Would you like to compare it to the structure of the Heat OM in the documentation that I linked to earlier? Also identify any deficiencies of that heat OM that would make it less usable from your perspective.
-
Yeah sorry. I was already typing when I saw your responses.
I'll take a look. -
One issue is that Bed, Chamber and Extra heaters are all defined exactly the same and it seems future-limiting to create distinct classes for things that share the same attributes. I'd also argue that BedOrChamber isn't a good name for what's there now because you're really describing a Bed or Chamber heater not the Bed or Chamber itself. Some day you might want a first-class object like Bed that has things like dimensions, what planes it moves in (if any), levelling points or levelling type, the mesh compensation matrix, homing location, etc.
Another issue is that things aren't cross-indexed. In a perfect world/pure object model you wouldn't do that but in the real world, it'd be very handy to know things like which tool(s) a heater serves without searching through the tools looking for it or which heater a sensor serves without looping through the heaters, especially if whatever's generating the model already knows the relationships.
It also seems odd that the sensors object has endstops and probes but not the temperature sensors. What if someone has environmental sensors that control nothing but just give the user info to help determine slicer parameters?
-
@gtj0 said in If I work on the heater model, where would you like it?:
One issue is that Bed, Chamber and Extra heaters are all defined exactly the same and it seems future-limiting to create distinct classes for things that share the same attributes.
I don't think Extra belongs there at all, it's probably a hangover from RRF2. I agree that Bed and Chamber should be combined into a generic heater collection class. We do need something to say which one is controlled by M140/M190 and which by M141/M191.
Another issue is that things aren't cross-indexed. In a perfect world/pure object model you wouldn't do that but in the real world, it'd be very handy to know things like which tool(s) a heater serves without searching through the tools looking for it or which heater a sensor serves without looping through the heaters, especially if whatever's generating the model already knows the relationships.
I would be reluctant to add cross-indexing to the model where this isn't already present in RRF. It's easier to build a cross index in the client (which is normally a web browser or program running on at least a Pi) than to take up precious RAM on the Duet to hold the cross index. We have no spare RAM on Duet WiFi/Ethernet. It's possible that we could extend the M408 P1 filter syntax to do this kind of search for you, e.g. M408 P1 F"Machine.Tools[] where *.heater=1". That would avoid having to retrieve all tools.
It also seems odd that the sensors object has endstops and probes but not the temperature sensors. What if someone has environmental sensors that control nothing but just give the user info to help determine slicer parameters?
That's because the sensors are mostly (but not exclusively) temperature sensors, so that are managed by the Heat class. Whereas endstops and Z probes are motion sensors. You can certainly argue that it's more logical to group all sensors together, but I don't think it's very important. We should consider adding analog and digital general purpose input pins somewhere too (analog ones will probably live in the existing Heat.Sensors collection, because we have type LinearAnalogSensor to support them).
-
Fair points but once RRF3 goes GA, it gets harder to change stuff.
-
@gtj0 said in If I work on the heater model, where would you like it?:
I'd also argue that BedOrChamber isn't a good name for what's there now because you're really describing a Bed or Chamber heater not the Bed or Chamber itself
You could surely call it SlowHeater but since the same object type is shared for beds and chambers, I see no reason why it's bad. Besides, bear in mind how RRF treats beds and chambers, they are treated as individual objects. You can use M140/M141 to create beds and chambers and to map heaters to them, so I still think they should be distinguishable from plain heater objects.
-
But the GCodes are historical/public/standard ways for users to address objects. That doesn't mean that internally we have to maintain the distinction if it means a smaller, more efficient, easier to maintain and easier to contribute to code base. Anyway, it's not a huge deal. Maybe it's something to think about for RRF4.
