I found the reason in the meantime: I've activated the Adruino plugin in SimHub before and it's on auto-start. The problem disappeares if I launch Sim Commander before SimHub or deactivate the plugin.

For me, the periodic failure of one or more gseat/belt to be seen by the software turned out to be a loose cable connection.  

I solved this by mounting the accuforce controller to a 12”x12” plywood board.  The twelve inches of height is enough to tie down the cable to the board in their natural position coming out of the controller.  

Before this, I had the issue every few times I used the simulator.  Now.  No problems.  Everything works 100% of the time.

Typically, if the problem is our Sim Commander software, it is seen in more than .0025% of customers. Since that's not the case, it's likely that the issue is something else.

It's good that we can see the AccuMotion controller present in your screenshot. 

The message "One or more output devices cannot be found!" doesn't necessarily mean that the G-Seat or G-Belt controller isn't being found. 

It can mean that one of the interfaces connected to the controller isn't being found. There is a memory chip in each G-Belt and GS-5 interface cable. It is programmed with information that tells Sim Commander what it is. This is how we know that you plugged in a back/left panel even though you can plug it to any port on the controller. If we fail to read one of the memory chips on the cables for the G-Seat, then the whole G-Seat is considered not present. Same true for the G-Belt.

There are typically only a few reasons why we might not be able to read the chip that's in the cables:

-Physical cable damage from cable strain
-Loosely connected cable(s). Just one loose is enough to cause the problem.
-Damaged pins on the controller that the cables connect to.
-Another app or driver interfering with the performance of virtual COM ports on your PC

I have seen an odd case or two where someone has COM / Serial port debugging software (sometimes for 3D printers or just in general) and this installs a shim driver. This shim driver injects itself between our driver and the hardware and intercepts our communications. It reduces performance to the point that some of the communications timeout and fail, ultimately causing us not to be able to read the memory chip reliably at startup. Other communications would have failed or have been intermittent due to the shim driver too, but in the case I observed, we don't get that far.

In any case, the forum is not very useful for support and troubleshooting. We'll need to collect some additional information and log files from your system, etc.. I'll create a support ticket from this post so we can begin gathering the necessary information.