Here is some guidance concerning steps you can take if your SP-ICE-3 Card is not working as expected.
This topic contains the following sections:
Troubleshooting Exception and Error Messages Troubleshooting General Problems Problem | Possible Cause / Solution |
---|
Host-PC is not booting. |
Is the SP-ICE-3 Card properly mounted in the PCIe slot?
Did any metallic parts fall into the housing of the Host-PC when mounting the card?
Are any connectors improperly mounted?
|
SP-ICE-3 Card is not responding.
|
Does the SP-ICE-3 Card's Power LED state indicate that the card is up and running?
Can the card be discovered with SP-ICE-3 Configuration Tool (SPICE3Config.exe)?
Is there anything untoward in the card's Error Log?
Is the correct SP-ICE-3 API DLL installed?
Is another application (e.g. SP-ICE-3 Configuration Tool (SPICE3Config.exe)) currently accessing the card?
Normally, only one application at a time should try to access a particular card.
Close all applications that access the card, and then run only one such application.
Does the application program itself have a bug?
|
Failure in application software. |
Is the application calling the correct SP-ICE-3 API DLL (ClientLib.DLL or NativeLib.DLL)?
Is the correct version of the SP-ICE-3 API DLL located in the application directory or in the search path of the application?
Are the all function calls used by the application completely implemented?
|
Control of scan system fails,
or scan system reacts unexpectedly.
|
Is there a proper connection and appropriate cable between the scan system and the SP-ICE-3 Card?
Is the scan system supplied with the correct voltage / current?
Are there any faults in the application software? Is the card status normal?
|
Control of laser fails,
or laser reacts unexpectedly.
| Is the correct laser interface being used? Are the delays set correctly? Is the card properly configured for the laser? Is the card status normal?
|
Security Certificate problem when accessing card's web interface. | All modern web-browsers attempt to verify the security certificates of websites they visit.
The SP-ICE-3 Card's web interface is presented to the browser via the HTTPS protocol, and sends a valid certificate to the browser, but the browser cannot find any Certificate Authority against which it can verify the certificate (this is especially the case when the card and Host-PC are connected in a Peer-To-Peer configuration).
Simply allow the browser to make an exception for the card's certificate.
|
Troubleshooting Connection Problems Problem | Possible Cause / Solution |
---|
ClientAPIConnect fails, although ClientAPIDiscover succeeds.
|
Check whether the card's Web-Interface is accessible: 17.2 How to Open the Card's Web Interface.
On the NETWORK page, check the Concurrent Connections limit.
On the STATUS page, is there anything untoward in the card's Error Log?
If the connection fails when using the card's IPv4 address, try its IPv6 address instead.
If you are using a hard-coded IPv6 address for the card in a custom application, check that the Scope-ID (i.e. the %nn part of the address) is still valid.
Important |
---|
Note that the Scope-ID is assigned to a particular network interface by the operating system of the Host-PC, and may change if another interface is added or removed from the Host-PC, or even if a SP-ICE-3 Card is merely moved from one PCIe slot to another.
In particular, the Scope-ID cannot be controlled or changed by RAYLASE software, and a change of Scope-ID does NOT indicate a bug or failure in RAYLASE software.
|
|
Discovery via IPv4 fails after re‑connecting the Ethernet cable on a P2P-installed card.
|
If we try to use Discovery immediately after re-connecting the Ethernet cable, the card is not found.
However, if we wait long enough before attempting discovery, the card will indeed be discovered as usual.
So how long is long enough in this context?
When the cable becomes disconnected, whether accidentally or deliberately, the card and the Host-PC both notice the fact, and proceed to forget everything they previously knew about the connection.
This includes the IPv4 addresses they were using to communicate across the cable.
Once the cable has been re-connected, the card and the Host-PC both start trying to find an accessible DHCP-Server which, they hope, will assign IPv4 addresses to them.
Note |
---|
Neither the card nor the Host-PC has any a priori knowledge concerning the nature of the network (if any) at the "other end" of the cable.
In particular, they make no assumptions about the way the card is installed.
|
If no DHCP server has been found after some time, they both assign themselves private IPv4 addresses in the 169.254.*.* range.
Earlier Windows versions allowed themselves up to 3 minutes (!) to search for a DHCP server.
Windows 10 seems to limit the search time to a few tens of seconds.
Summary: this is not bug.
In a P2P installation, you must allow the card and the Host-PC enough time to assign themselves private IPv4 addresses after the cable is plugged in (again), and before using Discovery.
|