Troubleshooting - Solving typical problems when working with WebHMI

Материал из WebHMI Wiki
Перейти к: навигация, поиск
Эта страница — перевод страницы Troubleshooting - Решение типовых проблем при работе в WebHMI. Перевод выполнен на 100%.

Другие языки:
English • ‎русский

The device can not be powered on or resets itself

When power is supplied, the PWR LED does not light

1. Power supply not connected or switched off
Check the power supply. Check if input voltage 24 Vdc is present on terminals
2. The problem is with power cable, terminals or polarity
Check power cable, contact and polarity


The device does not boot up. LEDs on front panel blinks regularly

1. No SD card or it's inserted wrong
Insert (correctly) SD - card.
2. "lock"-switch on the SD card is set into Write protect
Disable write protection for SD-card
3. SD - card is damaged
Check the SD card on the another device


The device does not boot up, SD card is Ok

1. WebHMI failure
Send the device to the service.


The device reboots

1. If 3G modem used, network watchdog reboot is selected in Monitoring modem menu (network setup)
Disable "reboot" checkbox in Modem monitoring properties
2. Bad contact in power cable.
Check contacts of the power cable
3. SD - card is damaged
SD-card can be checked in Setup->Network Setup->Status->System Log messages:
Mon Apr 11 11:54:43 2016 kern.info kernel: [  110.790000] sd 0:0:0:0: [sda] Unhandled sense code
Mon Apr 11 11:54:43 2016 kern.info kernel: [  110.790000] sd 0:0:0:0: [sda]  
Mon Apr 11 11:54:43 2016 kern.warn kernel: [  110.790000] Result: hostbyte=0x00 driverbyte=0x08
Mon Apr 11 11:54:43 2016 kern.info kernel: [  110.800000] sd 0:0:0:0: [sda]  
Mon Apr 11 11:54:43 2016 kern.warn kernel: [  110.800000] Sense Key : 0x3 [current] 
Mon Apr 11 11:54:43 2016 kern.info kernel: [  110.800000] sd 0:0:0:0: [sda]  
Mon Apr 11 11:54:43 2016 kern.warn kernel: [  110.810000] ASC=0x11 ASCQ=0x0
Mon Apr 11 11:54:43 2016 kern.info kernel: [  110.810000] sd 0:0:0:0: [sda] CDB: 
Mon Apr 11 11:54:43 2016 kern.warn kernel: [  110.810000] cdb[0]=0x28: 28 00 00 0b 61 10 00 00 f0 00
Mon Apr 11 11:54:43 2016 kern.err kernel: [  110.820000] end_request: critical target error, dev sda, sector 745744
Replace SC-card.
4. Internal power supply failure"
When turned on, all the LEDs light up, then fade out and light up again (the power supply is restarted, but if the internal circuit test fails, it turns off and then starts again, then everything repeats). In this case, send the device for examination to the supplier.


No access to WebHMI

Forgot or lost project password

1. Password is not documented
Clear the project. It is necessary to enter the network settings (if their password is also unknown, then you need to reset the network settings). Be sure to save the password, if you change the default password, the is NO (!!!) password reset option in WebHMI x(with the aim of protecting the intellectual property of project developers)


Forgot or lost network setup password

1.The password is not documented
Do reset of the netword settings.


Login/Password does not match

1.The password is not documented- see above.
2. Login or password is pasted from clipboard with extra space symbol.
copy login/password without spaces.


Unknown IP-address of the WebHMI

1.IP-address is not documented
  • Best thing is to reset network setup.
  • For complicate network settings on WebHMI, you may try to scan the network with one of the options.


It is impossible to load page in browser, ping exceeds timeout limit (even with Ethernet connection)

1. Ethernet cable plugged into WAN port, and firewall blocks incoming connections.
Plug patchcord into LAN port
2. Damaged patchcord
Replace the patchcord


It is impossible to load page in browser, ping exceeds timeout limit (Wi-Fi, connection when WebHMI is client for another wireless network)

1. WebHMI connection to other network has same network settings as default settings for LAN (192.168.1.0/24). In this case routing may not work properly.
Change LAN interface settings differently from Wi-Fi hot-spot setting, where WebHMI is connected to (e.g. to 192.168.0.1 etc.).
2. Network interface on the WebHMI is in WAN (firewall) zone.
Move interface into LAN firewall zone.


Unable to connect to WebHMI with Wi-Fi

1. Wi-Fi access point is disabled (no activity on WiFi LED)
Connect via LAN interface and turn on WiFi master interface
2. Weak signal in access zone- too far from WebHMI, EMI interference , Wi-Fi not in place
Plug antenna, come closer to WebHMI where signal is stronger
3. There is probably another WebHMI with the same SSID for wireless network.
Change SSID for wlan on either WebHMI.


Can not connect PC to WebhMI VPN

1. Error in PC WebHMI VPN connection settings.
Check settings - see [here]
2. OS services (Windows), necessary for VPN support are disabled.
Turn on needed services and make settings according to this document
3. Wrong protocol is selected in VPN connection settings.
See the chapter for network setup

In newer versions of Windows 10, there may be differences when creating a VPN connection from the standard control panel and from a new interface (Start menu, 'tiles'). When you create a VPN connection from the standard control panel for the VPN connection, the IKEv2 protocol will be used, if the new one is L2TP (PPTP). You need to make sure that the L2TP / PPTP protocol is used.

WebHMI VPN HowTo.png


You can create a new connection through the Start menu (Windows key), then in the quick search field type 'parameters'. In the followed VPN submenu, create a new connection. Windows 10 VPN 1.png

Connection parameters:

VPN Create.png

WebHMI can not detect another WiFi network

1. Wireless network has hidden SSID
Add wireless network in manual mode.
2. WiFi network works on other radio frequency (e.g. 5 GHz).
WebHMI supports frequency of 2.4 GHz. You need to change respective settings on wireless access point.
3. Wireless network uses different radio channels.
In WebHMI, the frequency channels used are determined by the region selected in the wireless network setting. Perhaps the current setting does not have a channel that is selected on the access point. You must reconcile these settings.

Communication on RS-485

In order to save time, it is recommended to make sure beforehand that the peripheral device with RS-485 is not only configured correctly, but also responds to queries of the test program, or it's software tool. It is desirable to have an alternative serial communication device USB or RS-232 -> 485 and a laptop (computer).

Preliminary verification will save a possible loss of time for setting up a connection, if this is done immediately from WebHMI. In the case of several operating peripherals and one 'problematic', it is recommended to disconnect all connections for operating devices, and only work with one device being set up. Then analyzing the possible cause will be easier with the help of diagnostic LEDs RX TX. For example, if only the TX diode is lit, then only the transmission is working, and not any reception. If the RX diode works, but not "mirrors" TX LED behavior, there are reception failures. In the absence of errors, the diodes operate alternately at the same frequency.

The Error LED also indicates the presence of communication errors.

There is communication via standard tool (485 converter and software tool), but not via WebHMI

1. Connection or register settings on WebHMI do not match those ones on device.
  • Make correct settings for 485 communication and register settings so to match with the peripheral device.
2. The connection using 485 on WebHMI is disabled or switched into virtual COM mode
  • Enable connection, switch virtual COM mode off.
3. RS-485 port on the end device has hardware peculiarities (pull-up down resistors or voltage level check, terminating resistor needed, common signal ground wire is needed etc.)
  • Put necessary resistors, use 3-wire circuit for RS-485.
4. RS-485 port is damaged on WebHMI.
  • You can check the functionality of the RS-485 port of WebHMI by creating a Modbus ASCII connection on it, and instead of the peripheral device, connect a laptop or computer with a USB-485 converter and start the terminal utility or the 'Modbus Slave' simulator. In case of absence of exchange (absence of reception in the terminal) with simultaneous operation of the TX LED, it is possible to conclude that the port is damaged.

Unstable reading registers

1. EMI on the RS-485 bus, bad contact.
  • Check the line (tightness of contacts, topology of the network - there should be a bus without radial branches, shielding - ground the shield at one point, the presence of terminating resistors of 120 ohms for RS-485, no shorts of the signal wires between each other and on the ground)
2. Communication rate too high
  • Slow down comm. rate
3. Small timeouts waiting for a response from slower devices. In this case, the re-reading of the register begins with the 'belated response' from the device, which leads to a collision.
  • Set a longer communication timeout
4. Peripheral device according to the documentation can work with different settings, however only a few of them work stable.
  • Try different comm. settings for the peripheral device.
5. The situation is possible when a 3G modem plugged into USB connector, and the system path (/dev/ttyUSB...) for 3G modem was chosen from already engaged device (serial port) (e.g. /dev/ttyUSB0 is used by the on-board RS-485), and network driver may interfere with serial port operation.
  • Specify the correct system path for the modem in the network settings (you can see the path in the kernel messages, the menu Maintenance \\ Kernel Messages).

Один из регистров не читается (всегда или с перебоями)

Another (adjacent in polling queue) device after the end of transmission has a 'long' transient process, which leads to a distortion of the communication with this 'problem' device
  • It is necessary for the connection, where the 'problem' register is located, to establish a greater 'stabilization time' (stabilization pause). Then before the communication in this connection starts, the necessary pause will be maintained.

Some of the registers in the working connection are not permanently readable

Wrong register addresses
  • Check register addresses. In the communication log (with the Debug and Trace levels set) for these registers, there will be detailed error codes and communication telegrams, which will allow to make thorough analysis of the cause.
The "Read On Demand" property is set for the registers.
  • Set normal or high priority for registers.
The Strict scan option is set in the project settings, which means that the registers with the usual priority, which did not have enough time to be read, are excluded from the polling queue.

  • Increase scan time, disable strict scan option
The device to which WebHMI is connected supports only double word exchange (Double Word). By default, the polling driver uses the word (Word) reading to read registers of Double Word type, so the device may not respond to an unsupported type of command.

  • It is necessary to allow the grouping of Modbus registers into blocks of length 2 in the connection properties. In this case, the Double Word registers (and also any blocks of 2 consecutive addresses will be read by one query.

Data

Data read is not correct

1.Wrong format and data type of the register
Check register's data format and type.
2.The peripheral device gives the data in a 'raw' form, not in engineering units
Use normalizing and scaling settings to get necessary accuracy and units


Trends are not displayed or has spaces

1. There are errors when communicating with the device
Get clean communication, see above.
2.The frequency of updating the trend on the dashboard is too high, for a given connection speed
Decrease trend refresh frequency


Gaps in graph data

1.Data from the device is not read
Get clean communication, see above.
2.The interval is too small Max graph interval
Increase the intervalMax graph interval


Data on the board is not updated

1.The frequency of updating the board is set too high for this connection speed
Reduce the frequency of updating the dashboard.
2. Connection is lost to WebHMI
Recover network connection


Programs

Program is not executed

1. There is a runtime error
Look through Communicatoin log. In the messages with ..lua script.. error line number is indicated.
2. Wrong program logic
To simplify debugging, add debug printing (functions DEBUG, INFO, TRACE) with output of intermediate results in Communicatoin log.