-
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.
Several causes
-
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.
-
Issues with MySQL in the moment the IBEX server was started (this seems to affect the archiver start up). Check logs of the MySQL service in the
vararea, fix any issues so that MySQL is running correctly again, then restart the IBEX server. -
If it works in your browser but not he users they may have a old cached copy (this shouldn't happen but we have seen it in Safari). Clear their browser cache and reload.
-
Try restarting
ARINSTon the instrument. It can happen that the archiver does not pick up all PVs to be archived on server startup. A symptom of this is that the configuration file underEPICS\CSS\master\ArchiveEngine\inst_config.xmlis very short compared to other machines.
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.
Value logs from IOC not produced/ARACCESS not creating log files/ENGINX Stress Rig not writing log files
Try the following as administrator on the machine that you are running remote desktop client on:
* Run gpedit.msc
* Navigate to Computer Configuration > Administration Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client.
* Set the "Turn Off UDP On Client" setting to Enabled.