Thanks for the suggestion given. really appreciate it... is there a simpler way to it other than using the hardware in the loop as you suggested? Hardware in the loop is quite advanced at this stage...
For the timeout wise if I adjust the timing by lengthening it to 10 seconds in the AE itself configuring the Modbus Initialisation Part API. do you think it might help solve it or I have a wait in the action cases itself to give it sufficient time instead?
To answer your questions on the free-running loops, the program does not read the enable VSD command when I place the AE alone in the Action Cases, hence I have to poll it and have a timeout for 5 seconds after the program read it and it moves on to the next action case after that ... true enough the program might be hard to follow as it took me quite a while to get the hang of it, the action queue is needed to define the queue in the QMH Loop, where the state logic enqueues the action and dequeues the various action in the action cases, hence is quite important in this template itself...
Well putting hardware in it's own loop is more of my personal style, I don't see anything that would prevent it from working with the AE's as you do. I just prefer it because if there is some hardware issue it doesn't freeze up any other part of the program and debugging and error handling is a bit easier if things are separated out.
If you are getting timeouts with your hardware I would start by trying to figure out why you are getting timeouts. I think the default for the modbus stuff is 10 seconds which should be plenty of time for hardware to respond. Are you getting timeout errors? Put some probes in your action engines and try to identify what error is happening and where.
For the loops that capture the "enable VSD" and "Frequency Control", you have an event structure, why not handle those events in there?