CH2014

Members
  • Posts

    73
  • Joined

  • Last visited

Recent Profile Visitors

2,591 profile views

CH2014's Achievements

Member

Member (2/5)

0

Reputation

  1. Hi Azeotech, Thank you for that. I hadn't thought of the ctl file corruption. OK I will look at creating a config. file that loads on startup. I have also tried the registry option which is working ok. I will try the read only folder advice for security. Wouldn't this stop writing changes to the ctl from a config file on start up?
  2. Hi When changing a Channels Device Number in Run Time mode using : - e.g. MyChannel.DeviceNumber = 147 How do you get DF to save this Device Number change when in Runtime Mode? It saves OK if I switch to Run Time Mode whilst in Development Mode (as it prompts to save when exiting). But if I start the app in Run Time mode and change the Device Number it doesn't save this change in the Channel parameters.
  3. Hi Azeotech, Thanks for that. I will modify the project to use the TEXT component instead.
  4. Hi, Is it possible to insert a line feed character into a string variable. In order to force it onto 2 lines in a "Variable Value Component"? I have tried chr(13) & chr(10) with no success.
  5. Thank you for the reply. I will do some googling to see whats available on industrial serial dot matrix printers.
  6. Hi, Is it possible in DF to print alarm states to a Dot Matrix Printer (Event Printer) So each alarm event would just print a line on the Dot Matrix Paper? I have had a look on the forum on printing from DF and it seems to suggest writing to a file and then printing the file. I was wondering if there was a more stream lined way of just printing a single line and then doing the line feed. Would it best to communicate to printer using serial connection and using the NULL protocol? Thanks
  7. Sorry for the delay in replying. Just getting back into the GSM modem project. Thanks for the useful information.
  8. 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.
  9. 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")
  10. 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?
  11. 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?
  12. 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?
  13. 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.