Home› AMX User Forum› AMX Technical Discussion
Options

Possible to change XDD file at runtime?

SCamphaugSCamphaug Posts: 23
in AMX Technical Discussion

Good Afternoon,

This question may be a little bit wordy but I hope it all makes sense. I have been using perhaps some of XDD's unintended "features" to create some ability to dynamically load device configurations from a text file located on our processors and deployed by DevOps. Essentially I have a fixed number of possible ports and victuals paired for all the possible display configurations in our systems, and a DeviceDriverEngine loading at runtime for each pair. On program load that configuration file is loaded into the systems persistent memory and if the XDD driver has changed, the system will reboot. One of the nice features of XDD is that without a file specified, that virtual will never load and thus I am able to somewhat dynamically assign both the number of displays, and where they are physically located on the controller while also providing the ability to easily change that configuration without changing code.

The issue that somewhat unexpectedly slapped me in the face while applying this same design to our MCP controllers is the lack of persistent memory on them, who knew? So what's happening is the DriverDesignEngine modules are coming up faster than I am able to pull config and provide them a file to load, Normally persistence handles this problem on the reboot after the config is loaded.

So I guess this questions one with some out of the box thinking required lol.

Is there any way I can delay module load? (No?)

Is there a way to specify XDD driver filename at runtime and force a reload of the module? (REINIT and RELOAD didn't pan out)

OR... Can I straight knock that module down and reload it?

Any other wild or crazy ideas would be very much appreciated.

Comments

  • Options
    HARMAN_icraigieHARMAN_icraigie Posts: 660

    Check out NetLinx.axi - you will find system functions to load and unload duet modules. The load function is essentially all that is in the module tko file that is called from DEFINE_MODULE. The properties parameter is a set of key value pairs that mirrors the manifest of the module - the complete set is observable in Diagnostics when the module boots up. Not sure if this will solve your problem but it might help.

  • Options
    SCamphaugSCamphaug Posts: 23

    You are a rockstar my friend!

    Example if anyone else is interested.

    DEFINE_FUNCTION LoadDeviceDriverEngine(DEV vdvDevice, DEV dvDevice, CHAR XDDDriver[]){ STACK_VAR DUET_PROPERTIES[10][70] DUET_PROPERTIES[1] = "'Physical-Device=',FORMAT('%d:',dvDevice.NUMBER),FORMAT('%d:',dvDevice.PORT),FORMAT('%d',dvDevice.SYSTEM)"; DUET_PROPERTIES[2] = "'Duet-Device=',FORMAT('%d:',vdvDevice.NUMBER),FORMAT('%d:',vdvDevice.PORT),FORMAT('%d',vdvDevice.SYSTEM)"; DUET_PROPERTIES[3] = "'Protocol-File=',XDDDriver" DUET_PROPERTIES[4] = 'Duet-Module=DeviceDriverEngine' DUET_PROPERTIES[5] = 'Bundle-Version=1.0.0' DUET_PROPERTIES[6] = 'Device-Category=serial,ip' DUET_PROPERTIES[7] = 'Device-Make=AMX' DUET_PROPERTIES[8] = 'Device-Model=DeviceDriverEngine' DUET_PROPERTIES[9] = 'Device-SDKClass=com.amx.duet.componentsdk.base.Module' DUET_PROPERTIES[10] = 'Device-Revision=1.0.0' LOAD_DUET_MODULE(DUET_PROPERTIES) }

    Works a treat Ian, I can't thank you enough.

Sign In or Register to comment.