• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About CH2014

  • Rank
  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. 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.
  9. 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?
  10. 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)?
  11. CH2014


    Hi, Thank you very much. I will give it a go.
  12. 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"
  13. Thank you for the clear and detailed reply. Interesting options. Excellent, thanks again.
  14. Thank you for the reply. I've noticed that a single line of code (as per below) in a startup sequence does not add any data to the channel if the #HST = 10. It does however add data if the #HST = 1 ////////////////////////// TempSensor101.AddValue(0) ////////////////////////// If I change the code in the start up sequence to the following: - //////////////////////////This adds the 10th value to the TempSensor101 channel if #Hst = 10. TempSensor101.AddValue(0) //1 TempSensor101.AddValue(0) //2 TempSensor101.AddValue(0) //3 TempSensor101.AddValue(0) //4 TempSensor101.AddValue(0) //5 TempSensor101.AddValue(0) //6 TempSensor101.AddValue(0) //7 TempSensor101.AddValue(0) //8 TempSensor101.AddValue(0) //9 TempSensor101.AddValue(0) //10 This 10th value is added to the TempSensor101 channel if #Hst = 10. The channel will now have one value at [0] ////////////////////////// The while loop just avoided the repeated lines above. The TempSensor101.Time = sysTime() line of code in my post was a mistake, sorry. The reason for wanting to do manually add the values to the empty channels is that I may not have access to the PC that will be running the modified DF application. If I did have access to the PC I would be able to add the values myself using something like the "SimplyModbus" test program during the DF application test. Approx. 50 sensors have been added to the System. I don't want my DF program failing to start during commissioning because no data is in the NEW channels. Also, during the commissioning stage there is no guarantee that the 50 new sensors will be working correctly initially (connection errors etc.). Note: My DF program has all channels set to #Hst 10 and Persistance to 3144960
  15. Is the following code snippet a valid way of adding data to empty channels. The snippet would be incorporated within a startup sequence. Reason: I have an application that references channel names in functions but some of the channels are not currently active so the sequences stop working with an error such as "One of the parameters was empty". The #Hst is set to 10 for the all the channels. global timer1 = sysTime() while((sysTime()-timer1)<5) TempSensor101.AddValue(0) TempSensor101.Time = sysTime() TempSensor102.AddValue(0) TempSensor102.Time = sysTime() TempSensor103.AddValue(0) TempSensor103.Time = sysTime() TempSensor104.AddValue(0) TempSensor105.Time = sysTime() //etc //etc endwhile