All of the verification checks pass. Even opening up ACE client, shows a check in the Enable box for the specified PackXpert process. The problem is, the process that is running is the last process that was Enabled, not the one it currently shows is Enabled. If the controller was just powered on, no process is running, even though one is shown to be Enabled. If I stop and start the PackXpert process manager a second time, it corrects itself.

To be clear, if I power up the controller, specify Process 0 from my program, run my start sequence, and put a Process 0 part on the conveyor, nothing happens. If I stop and start PackXpert, a Process 0 part will now get picked up. If I then select Process 1, run my startup sequence, and put a Process 1 part on the conveyor, it won't get picked up. If I put a Process 0 part on the conveyor, it will get picked up, even though ACE client shows Process 1 is Enabled.

So, I can get around this issue by restarting PackXpert a second time in my startup sequence, but I'm trying to cut down on my startup time. Also, the API calls, along with the ACE client, are returning incorrect information.

This issue was just reported last week and has been logged as a bug. The issue is that while the PackXpert is establishing communications with the controller and downlaoding all the data objects (like the process information), any changes to the data are not being properly detected. The workaround is to either make sure you change the enable/disable state of the processes before starting the PackXpert -or- add a delay after starting the PackXpert and before enabling/disabling the processes.

I expect this issue will be fixed in the next few weeks. It may not make it in the release this month, though ...