• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About CH2014

  • Rank
  1. Further to the above, the dummy modbus device was set to device ID D# 0 Or should I be using : - daqconnect.addValue("tagName", value) i.e. daqconnect.addValue("LevelStatusDAQconn", LevelStatus) ?
  2. Hi, Is the best way to make DF Sequence variables available to DAQconnect : - 1. Create a new channel (named e.g."LevelStatusDAQconn") using a dummy modbus device and then ticking the DAQconn box and filling out the DCHst and DCintvl columns 2. In the applicable DF Sequence copy the actual variable to the channel "LevelStatusDAQconn" variable (i.e. LevelStatusDAQconn = LevelStatus) Doing the above worked fine but I just wanted to check that this is the best way?
  3. Thanks for that. I try to keep on top of the indentation but it looks like I have missed some areas. I will look at converting to the bit math method. The app is still working fine (7 days) with the BIOS "C-State Report" disabled. What are your thoughts on the Windows 10 control of C-State?
  4. Further to the above. I have been in contact with the HMI hardware manufacturer. They said the only similar issue whereby another customer had a total freeze-up of the hardware was related to the "C State Report" setting in the BIOS. The solution was to disable the "C State Report" setting. I have now disabled "C State Report" in the BIOS and now checking to see if it has solved the problem.
  5. Hi, Further to all the above posts and in particular my last post. Although Windows Defender anti-virus did affect the performance of DF whilst doing its virus scan it was not the cause of the lockups described in this thread. The lockups are still occurring but what was not mentioned above is that the lockups are in fact complete PC freeze ups. Even the keyboard BIOS does not respond (confirmed by CAPS LOCK LED not operating). I'm thinking that this is some sort of hardware failure but the thing is, it only seems to happen when running the DF application on this particular HMI hardware. I have used stress test software to test GPU, CPU, RAM plus Test Write Temp files. All tests PASS OK. As mentioned above the DF application works without problem on for example a Windows 10 laptop whereby the only main difference being that the laptop has a magnetic drive as opposed to the HMI which has an SSD. Have you ever known a DF app to completely lockup a computer? I found out today that the same thing seems to be happening on an identical HMI with the same DF app running. On rebooting the HMI, sometimes the Persist file directory is corrupted and needs to be recreated. Just to recap. There is a Persist directory that contains 104 DAT files (each file is set to hold 3144960 values) file size (approx) 47.9mb each. The #Hst is set to 10.
  6. Hi Again, With ref. to the above problem. I now have access to the identical HMI hardware (op sys: Windows 10) and have been running the DF program for approx. 6 days now. A few days ago I noticed that the DF app operating very abnormally. i.e. All the DF sequences had significantly slowed down (e.g. comms polling, screen animations) plus the Windows Spinning Blue Circle was momentarily being displayed along with some screen freezing. I checked "Windows Task Manager" and noticed a background process called "Antimalware Service Executable" reporting quite a high CPU usage. "Antimalware Service Executable" is the process name for Microsofts "Windows Defender" virus program. After googling, I noted that "Windows Defender" can at times have a very high CPU usage causing software programs to slow down or crash. The only way to permanently disable "Windows Defender" Real Time protection is to install a 3rd party Anti-Virus Program or (A. an edit registry option or B. Add the entire C:\ drive to the "Windows Defender" Exclusions option in the "Windows Defender Security Center") plus switch OFF the Real-Time Protection switch in "Windows Defender Security Center" Note:- Doing all this is OK on this HMI system as its dedicated to the DF program (i.e. with no internet access). Anyway, since disabling "Windows Defender" the DF app has been working smoothly & perfectly. I will however still keep checking just to be sure.
  7. Thanks for the reply. I might have access to the actual HMI soon so I will do some checks on the actual hardware and see if I can see what the problem might be. If I can't spot anything I will email the .ctl file thanks. Just for extra info, I have had the app working perfectly on an old (2008) Asus Eee900 PC (Celeron M 353 with 2GB of Memory) slightly sluggish on the screen actions but otherwise functionally fine. It's been running for 8 days without any problems.
  8. Its happened twice in last 3 weeks. Nothing has been done to the auto updates settings as the hmi is not connected to the internet.
  9. The client ran the error checking on the SSD and no errors were found. So something else is corrupting the Persist Directory. As mentioned above, I've not had any problems with the application running on a Windows 10 laptop. Do you know of any Windows 10 issues that might cause the Persist files to become corrupted? Is it possible that a Windows 10 issue is causing DF to freeze/crash which in turn is then damaging the Persist files? Some info: DF is run in Administration mode and the Persist Directory has "Permission for everyone" set to Full Control, Modify & Write. Could the sleep settings in Windows 10 Power Managment cause a problem?
  10. On further checks. The drive is an SSD (64GB). With ref to your July 28 post above: - "Newer SSD drives should ???? wear level and this should not cause a problem, however, it does mean that if this pointer is corrupted then things go to hell" Is this statement entirely referring to SSD's? The DF app froze again earlier this week (Blank White Screen, Spinning Windows 10 Halo) after about 9 days of nonstop operation (Note: There was no power failure). App worked again after renaming Persist Dir to PersistOLD and recreating Persist Dir & Files. (Note: App has been working perfectly on a Windows 10 laptop) I have asked the client to run chkdsk on the SSD. Just waiting for the results.
  11. Thanks for the quick reply and the useful information. There is a "log to file" also set up in the application, the persists are just used for the graphs. I will try out your suggestions just in case the problem crops up again. Last question: If the HMI lost power while the DF was processing the write to the persist file. Could this cause a file corruption?
  12. Hi, I have a DF application running perfectly on a Windows 10 laptop. There is a Persist directory that contains 104 DAT files (each file is set to hold 3144960 values) file size (approx) 47.9mb each. The application was moved to the clients HMI (also Windows 10). After about a week of random use, the DF application starting to crash on startup (including Daqfactory.exe itself). I was not able to gain access to the DF Command/Alert utility to see what the error might be. However, I eventually determined that there was some sort of corruption within the Persist directory. i.e. After deleting the Persist directory and then allowing the DF to recreate the Persist directory and the 104 DAT files the application started working again. Some questions: - 1. What can cause the Persist file to become corrupted? 2. Is there any way to pinpoint the corrupted DAT file (as it seems a bit drastic deleting all the DAT files)? 3. Is it possible to repair the DAT file (as potentially quite a lot of data could be lost)?
  13. CH2014


    Hi, Thank you very much. I will give it a go.
  14. Hi, Is it possible on the TANK fill feature to do the following (a possible customer has asked a question)? I am using version 5.91. "Tank display shall be corresponding to the tank level, a lighter shade to be used to reflect real time level change"
  15. Thank you for the clear and detailed reply. Interesting options. Excellent, thanks again.