Plugin too fast for Constructor macro

[beefy]

Hi Balazs,

here's a copy of something I posted on Cnczone (I thought the forum was still down, my link button didn't work anymore):

I've just found out an interesting connection between DROs which are kept persistent by the Constructor and Destructor macros (Writekey and Readkey), and a plugin which reads those DRO values.

I had code in the "firstrun" block of the plugin 25hz loop method. This code reads the value of a persistent DRO.

However I just couldn't figure out why the DRO value was not being read, then I though maybe the plugin starts very quickly whereas the Constructor macro is a bit of a snail and takes time to finish doing its thing (i.e. writing the value to the DRO).

It appears this theory may be correct because I got things working by having a countdown in the 25hz loop before any of my loop code ran. In my case I had to let the 25hz loop run a minimum of 5 times without executing any of my code.

I would guess that with a Constructor macro with a lot more code it would take longer to complete and therefore a plugin which needed to read "persistent" DROs would have to "delay" for longer before it attempted to read those DROs.

I've asked Cncdrive if it would be a good modification to UCcnc to prevent plugins running until the Constructor macro has completed, otherwise if a plugin immediately attempts to read a "persistent" DRO but the Constructor macro hasn't yet written the value to that DRO..................................

Any thoughts on that one ??

Keith

[CT63]

I've run into the same thing and it took me awhile to finally figure it out. I agree plug in's should be delayed until the constructor macro runs.

[cncdrive]

This is an interesting question, because the question is what should run first?
The constructor macro or the plugins?
I mean in both cases there is a problem, if the constructor macro runs first then there is a problem if it works together with any plugins,
and if the plugins run first then there is a problem if it needs things to be done by the constructor macro.
So, what could be the good solution for this?

Now I think the plugins started first and after the constructor macro, but will have to check to be sure.

[beefy]

That way I see it IF the plugin NEEDS special functions such as updating persistance DROS to work properly then you should use First RUN to update the ones that need it done.

Terry,

any particular reason why you choose the "firstrun" block in the 25hz loop instead of the Startup_event() method. Just curious.

I haven't got around to trying it in "firstrun" but I did try creating persistent DROs in the Startup_event() and Shutdown_event() methods and couldn't get it to work. I'm wondering if the plugin runs BEFORE the screenset loads, and/or shuts down after the screenset "shuts down".

There's another thought.

Keith.