CH2014

Members
  • Content Count

    66
  • Joined

  • Last visited

Community Reputation

0 Neutral

About CH2014

  • Rank
    Member

Recent Profile Visitors

2,275 profile views
  1. CH2014

    sms message

    Sorry for the delay in replying. Just getting back into the GSM modem project. Thanks for the useful information.
  2. CH2014

    Graph Trend Line between 2 points changing

    OK, thanks for the reply.
  3. I've noticed that if DF has been switched OFF for a few days. The trend line between the data points that DF was switched OFF keeps changing every few seconds. See the attached images (period: day 17th and day 18th). The graph is a 7-day graph. It's not a major problem as DF will normally be ON all the time. I was just looking for any suggestions on how to stop this.
  4. CH2014

    sms message

    Further to my last post. I haven't actually got any hardware to try it out on yet but is the following command going in the right direction? device.gsmmodem.write("+CMGS")
  5. CH2014

    sms message

    Hi, Further to the above I can see that your suggestion of using email to send SMS is far easier. However, if the site engineers mobile service provider does not provide this facility is there an example of DF script that contains typical GSM AT commands? I assume I need the DAQFactory Serial - Ethernet communications guide. This does not seem to be in the installation folder?
  6. Hi, Further to the above. Its been a while but yes definitely better with Bit Math thanks. Managed to drastically reduce the code plus also used a function for the repetitive in between code. With ref. to your reply above i.e. Any bits 0-2 on and bit 3 off: min(((S & 0x0f) < 8) && ((S & 0x0f) > 0)) Is there a typo and should be max(((S & 0x0f) < && ((S & 0x0f) > 0)) ? Also, An unrelated question to the topic. Is it OK to have DF alarms setup with a condition code that includes a non-existent channel name? I haven't noticed any errors but thought I'd ask. The reason for asking is that I want to avoid having to delete alarms when modifying the application to a smaller system.i.e. can I just leave the unused alarms in place?
  7. 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) ?
  8. 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?
  9. 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?
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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?