-
Notifications
You must be signed in to change notification settings - Fork 2
Other Troubleshooting
This happens when windows locks a file for you. The lock can either be because of a local process or because of a file is shared from another computer.
Close items that might be using the file, especially command line consoles in that directory. If you still can't find it load "Process Explorer" (sysinternels some of the machines have this in the start menu). Thn click Menu
-> Find
-> Find File or Handle ...
type the path and this will give you the process id that is holding the lock.
If it is through a share the file lock will not appear in here. In this case look at the share information then kill the share. It may reconnect so just do the operation quickly.
Check to see if you have any errors similar to the following:
[2016-11-07 16:04:49] CoCreateInstanceEx (ISISICP) : Class not registered
If so, you haven't registered your isisicp.exe
program with the registry. Follow the steps to Configure DAE for simulation mode on developer's computer
If you have done this it may be that the isisicp.exe program is too old. Older versions do not contain a function which is needed by IBEX. Check the file svn_revision.txt in c:\labview modules\dae - it needs to be 1633 or higher. If it needs updating, ask a SECI specialist to update the program.
Check that the instrument is in the list of Instruments in https://github.com/ISISComputingGroup/JSON_bourne/blob/master/webserver.py and that the version on web server is up-to-date.
Try deleting any CMakeCache.txt
files in the appropriate directory
We encountered this issue in August 2017 on HRPD. Neither SECI nor IBEX could communicate with the MOXA. We solved the problem on the fly by remapping the ports from COM blocks 5-20 to 21-36. NPort Administrator had several ports in the former block marked as in use in spite of no devices being active. The ultimate fix was to clear out the offending registry value:
- Click start → Run → type regedit and click OK button
- Navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\COM Name Arbiter
- Now on the right panel, you can see the key
ComDB
. Right-click it and click modify - In value Data section select all and delete reset to zero
- Restart the machine if needed (to do this remotely use the command
shutdown -r -t 0
A similar (but I think unrelated) problem was found in June 2018 on ZOOM. Some ports in a MOXA were found to not communicate with a Julabo. According to both the lights on the MOXA and the MOXA's web interface there was data being transmitted both to and from the device. However, when transmitting to the device (either via hyperterminal or IOC) no actual data was received. Restarting the MOXA had no affect. The problem was ultimately not resolved, the julabos were moved to different ports.
When trying to use Make to build IOCs you might encounter an Error 2. The failing Make will look something like this:
process_begin: CreateProcess(NULL, echo Generating runIOC.bat, ...) failed.
make (e=2): The system cannot find the file specified.
This can be a result of having an environment path for git that points to git/bin
. If it is, then make will think you are on linux and then the build will fail. You must change this to be git/cmd
to point at the Windows binaries.
See also Ticket 4201 for a potential fix.
If PVs are visible in R3 then probably the gateway on the control service machine need to be updated.