Parameter behavior change from 3.4.6 to 3.5.4
-
Hi,
For a longish time I have been using firmware 3.4.6 without issue.
But it was time to update to 3.5.4 to see what is new and different.
So far I found a couple of things that have changed and I was wondering why.
First thing:
I have a number of places where I have something like this:
M291 R"Some Action" P"Busy" T0
then some code doing that action and a bit later
M291 R"Some Action" P"Done" T3
Under 3.4.6 the T0 resulted in the first message being displayed until the second one was reached.
Under 3.5.4 the T0 results in the first message being displayed until the Close button is clicked.
How do I get the old behavior?
Second thing:
Under 3.4.6 I used
M98 P"some_g_file".g ?
where the ? was a parameter letter indicating an option to be acted upon in the code.
Rather than use the value of a parameter I just checked for the existence of different parameters.
Under 3.5.4 a parameter without a value generates an error.
I have a lot of changes to make to deal with that change.
Why were these two changes made?
Thanks.
Frederick
-
@fcwilt I'd guess this change to M291 from the changelog https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x between 3.4.6 and 3.5.1 causes the first behaviour:
Feature improvements and changed behaviour:
- M291 messages are now queued. When a M291 command is executed the new message is added to the end of the queue, and any non-blocking messages already in the queue have their timeouts reduced to 1 second. If the queue is already full then the oldest non-blocking message is cancelled, or if there are no non-blocking messages in the queue, the oldest message is cancelled. The queue length is currently 8 messages.
Maybe change the M291 mode to S0? This is non-blocking with no button displayed.
Other changes:
Feature improvements and changed behaviour:
- M291 command now supports new message box modes 4, 5, 6 and 7. These are supported by DWC but not yet by PanelDue.
- In SBC mode the M291 P1 command didn't work correctly
Bug fixes:
- Extra indentation following a M291 command inside an if-block could cause a further nested if-block not to execute (https://github.com/Duet3D/RepRapFirmware/issues/897)
- If M291 was used to produce a lot of messages from more than one input channel, stack overflow messages could be generated
- If a M291 S1 message box was closed in DWC manually before it timed out, a spurious M292 error message was generated
For the other issue, it's this change:
Breaking changes and other important upgrade notes:
- Previously in an M98 or G29 or G32 command it was possible to pass parameters whose values were expressions that normally need to be enclosed in { } for example M98 P"myMacro.g" Strue and to create null parameters using M98 P"myMacro.g" S. This is no longer permitted and will give rise to an error message. Use e.g. M98 P"myMacro.g" S{true} and M98 P"myMacro.g" S{null}.
ie you can't create a null parameter without actually setting it to null.
Ian
-
Thanks VERY much for the extensive reply.
I'm off to edit all of the places where I need to change T0 to T1 and to add the explicit null - and there are a lot of places.
Frederick
-
@fcwilt As to why these changed, again that's one for @dc42. I think it's mostly because the M291 code was tidied up (it has been a bit of a muddle for a while), and new dialogue box formats added. The null parameter issue was presumably not to create unnecessary or unspecified parameters in the OM, and probably allows easier release of the memory once they are out of scope.
Ian
-
I have no doubts that the changes made are for good reasons of which most of us are not aware.
As often said, the one constant in life is change.
Frederick
-
@fcwilt said in Parameter behavior change from 3.4.6 to 3.5.4:
I'm off to edit all of the places where I need to change T0 to T1 and to add the explicit null - and there are a lot of places.
It doesn't need to be
{null}
if you are not interested in the value, you can use e.g.0
instead. The point it that a value of some type must be provided.