RRF 3.1 and DSF Object Models incompatible

gtj0

Structure is different.
Naming is different
Where naming is the same, the case doesn't match.

This is going to make it very difficult for folks who have to work with both models.

chrishamm

... obviously. Some structures will be changed in DSF 1.3 to match the new RRF OM but don't forget that the current RRF OM isn't frozen yet. I have been busy with the configtool and DWC2 so I haven't had a chance to review everything in detail yet. I hope I can find time to review everything in approx. one week.

Also, the case matches the internal DSF structures, but in the long-term I agree it would be better to provide those properties in camelCase where the first letter is lower-case in order to match the IPC structures provided by DSF.

gtj0

I just don't want to get too far down the line and then hear "Well it's too late now because people are used to it this way"

dc42

@gtj0 said in RRF 3.1 and DSF Object Models incompatible:

@dc42 and @chrishamm ...

Structure is different.
Naming is different
Where naming is the same, the case doesn't match.

This is going to make it very difficult for folks who have to work with both models.

Please provide examples so we can bring them into line. Note, the change from the Electronics (DSF) to Boards array (RRF) is deliberate and agreed between me and chrishamm, so expect the next major release of DSF to have this change.

gtj0

Well, all you have to do is compare the 2 json output, but ok...

RRF: Top level element is "key" with an empty value, then everything is "value"
DCS: Top level element is "result" with everything under it.

Apart from the name, electronics/boards is different:
RRF

      "Boards" : [
         {
            "FirmwareFileName" : "Duet3Firmware_MB6HC.bin",
            "IAPFileNameSBC" : "Duet3_SBCiap_MB6HC.bin",
            "IAPFileNameSD" : "Duet3_SDiap_MB6HC.bin",
            "MaxHeaters" : 16,
            "MaxMotors" : 6,
            "Name" : "Duet 3 MB6HC",
            "ShortName" : "MB6HC"
         }
      ],

DCS:

      "electronics" : {
         "expansionBoards" : [],
         "firmware" : {
            "date" : "2020-01-10b2",
            "name" : "RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0",
            "version" : "3.1alpha"
         },
         "mcuTemp" : {
            "current" : 34.4,
            "max" : 34.5,
            "min" : 33.7
         },
         "name" : "Duet 3 MB6HC",
         "processorID" : null,
         "revision" : "0.6",
         "shortName" : "MB6HC",
         "type" : "duet3",
         "vIn" : {
            "current" : 25.2,
            "max" : 25.4,
            "min" : 9.3
         },
         "version" : "1.2.3.0"
      },

Heat is different:
RRF:

      "Heat" : {
         "ColdExtrudeTemperature" : 160,
         "ColdRetractTemperature" : 90,
         "Heaters" : [
            {
               "Current" : 20.6,
               "Sensor" : 0,
               "State" : "Off"
            },
            {
               "Current" : -273.1,
               "Sensor" : 1,
               "State" : "Off"
            }
         ],
         "Sensors" : [
            {
               "LastReading" : 20.6,
               "Name" : "Bed",
               "Type" : "Thermistor"
            },
            {
               "LastReading" : -273.1,
               "Name" : "HotEnd",
               "Type" : "Thermistor"
            },
            {
               "LastReading" : 20.2,
               "Name" : "Bed Check",
               "Type" : "Thermistor"
            },
            {
               "LastReading" : 19.7,
               "Name" : "Ambient",
               "Type" : "Thermistor"
            }
         ]
      },

DCS:

      "heat" : {
         "beds" : [
            {
               "active" : [
                  70
               ],
               "heaters" : [
                  0
               ],
               "name" : null,
               "standby" : [
                  55
               ]
            }
         ],
         "chambers" : [],
         "coldExtrudeTemperature" : 160,
         "coldRetractTemperature" : 90,
         "extra" : [
            {
               "current" : 31.8,
               "name" : "*Bed",
               "sensor" : null,
               "state" : null
            },
            {
               "current" : 23.3,
               "name" : "*HotEnd",
               "sensor" : null,
               "state" : null
            },
            {
               "current" : 31.6,
               "name" : "*Bed Check",
               "sensor" : null,
               "state" : null
            },
            {
               "current" : 22.5,
               "name" : "*Ambient",
               "sensor" : null,
               "state" : null
            }
         ],
         "heaters" : [
            {
               "current" : 31.8,
               "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",
               "sensor" : 0,
               "state" : 0
            }
         ]
      },

etc...

dc42

The values returned by RRF are as documented in the html doc files in the DSF github repo. That's why the names all start with uppercase characters. Chrishamm and I will sort out whether to make everything start with uppercase or not.

I can easily change RRF to return "result" instead of "value". "key" is the query string you sent in the M408 P1 F parameter. It's needed when using a serial connection, so that you can tie up a response with the original query, allowing for possibly delayed or lost responses.

RRF doesn't yet implement the entire OM documented in the DSF project, which is why DSF has some fields not yet present in RRF. Likewise, DSF lacks some important properties that I have included in RRF, for example Heat.Sensors. These will be added to DSF.

dc42

The latest RRF commit uses camelCase for the property names instead of UpperCase. It also replaces M408 P1 by M409 and replaces "value" by "result" in the returned JSON object.

I've added some more values to the RRF ON, but there are still values in DSF not in the RRF OM (mostly because I haven't implemented them yet), and vice versa (because features have been added to RRF after the DSF OM was designed).

wilriker

@dc42 said in RRF 3.1 and DSF Object Models incompatible:

It also replaces M408 P1 by M409 and replaces "value" by "result" in the returned JSON object.

There's a bug with that. Here is how my result output starts:

{"key":""{"flags":"","result":{"boards":

This is no valid JSON because there is a { instead of , after the value for "key" and "flags".

wilriker

Also not very important but nevertheless:

{
    "lastReading": 0.0,
    "name": "TMC",
    "type": "TMC2660 temperature warnings"
},

type is not correct for Maestro/Duet 3 boards.

gtj0

Oh one of the most critical things is for @dc42 and @chrishamm to get the PID parameters sorted. Right now issuing an M500 overwrites an existing config-override.g with...

; config-override.g file generated in response to M500 at 2020-01-14 11:04

; Heater model parameters
M307 H0 A C D S V B0
M307 H1 A C D S V B0
; Workplace coordinates