AzeoTech

Administrators
  • Content Count

    5,671
  • Joined

  • Last visited

Posts posted by AzeoTech


  1. There are actually very few times it is used as a command as it is largely left over from when DAQFactory had table driven sequences which was like 18 years ago.  It is used most often for the U12 driver as the U12 is equally old and its driver thus developed during the time before proper scripting.  The UE series devices I believe only use it for specifying the second input to use for differential analog inputs.  OPC uses it for specifying the actual OPC tag (thus the OPC part of its name) but usually you should use the OPC browser to pick it.  Other than that I can't really think of any other places a driver utilizes this field, thus the reason most people just use it for channel notes.


  2. Its actually more about the historical graphing than anything else.  I'm working on a system with a single Atom that runs 3 copies of DAQFactory simultaneously (to connect to three identical systems), but using OPC, but with about 1000+ channels each.  But most of the automation is being done in the PLC, and DAQFactory is largely just an HMI in this case.  The HMI has minimal historical trending, but does log to a CSV about 100 channels.  The Atom is more than capable for this application and really only bogs down when I fire up the PLC's development environment, which is a bit of a behemoth and has nothing to do with DAQFactory.   For that I had the customer buy an i7 laptop so that we don't have to run that PLC programming software on the atom.

    I'm working on a separate Atom powered system that is only about 15 tags, but does things at high speed (50 hz software sampled data rates) and stores and trends huge amounts of data.  For this application I feel like the Atom was a bit underpowered.  It works fine for the acquisition, but when they do the analysis and trending, it seems a bit sluggish for my taste.

    In general DAQFactory is 20 years old and was originally designed at its core to run on slow PC's 20 years ago.  Even the slowest of today's computers are way faster than ones available 20 years ago, so DAQFactory should do fine.  The issue often comes down to the OS: is the processor fast enough to adequately run the latest version of Windows?  After that, it unfortunately comes down to the details of your application and, if the application has a lot of data processing, how efficient you are in your scripting, but this really only applies on more advanced applications.


  3. You don't really need the delay() between calls as the CPU is released while waiting for a response.  You do need a delay inside any error handling, i.e.:

    while(1)
       try
          // read the devices
       catch()
          ? strLastError
          delay(0.1)
       endcatch
    endwhile

    If you don't then if there is a typo in your code, or some other error, it will get repeated without any CPU release, tying up that CPU and possibly hanging or at least greatly slowing DAQFactory.

    A few notes on your app:
    1) 115200 is quite susceptible to noise due to the duration of each pulse, so be especially diligent with your shielding and termination
    2) there is often required a 10 to 20ms delay in polls when switching between multiple devices on a multidrop system.  This is because the transciever on the first unit will "hold the line" and not allow you to move on.
    3) for the above reason, and because DAQFactory is multithreaded, you can get much higher data rates if you put each device on its own RS485 line and then have separate, concurrent running script to poll each device

    As to your original question, you can always use the time stamp of your data points to determine throughput.  Or add script to do so using the system clock.


  4. You can always just not use the built in slider and either use the separate Slider component, or another component (like up/down arrows) to scroll.  To do this, you need a variable with the top index, for example:

    global tableTop = 0
    global tableRowCount = 20

    Then, in the table, you should subset all your columns:

    myData[tableTop, tableTop + TableRowCount - 1]

    Then, use a scroll bar component or other components to adjust the tableTop variable accordingly, limiting it to 0 to however many rows you have.


  5. There is a limit defined in the Modbus spec.  I don't remember off hand what it is, but I think it is 63 bytes of data for RTU, and each register is 2 bytes.  But don't take my word for it on the exact number.  The point is that it is a Modbus limit, not DAQFactory, though DAQFactory enforces it.  Also note that some devices don't support setting of multiple registers.  This is not your case, as it is obviously working with 16 registers.  I simply mention it for others that may have issues trying to set more than one at a time.

     


  6. You can definitely do it through script.  Just pass an array for data points.  So for example:

    device.mydevice.setRegisterS32(1, 100, {1,2,3})

    which would set register 100/101 to 1, 102/103 to 2, and 104/105 to 3 (register pairs because of the S32 of course).  Note that it is "Set" not "Write", and is "Register" not "Holding" because Input Registers can't be set, so there is no reason to differentiate on the output side.

    Note that with channels, DAQFactory will automatically combine reads of the same type into a minimum number of calls if they are consecutive and the same data type.  It will not fill in blanks, though, so sometimes its best to create dummy channels.  That said, on the output side you cannot do multiple outputs with one query through channels because there is no way to set multiple channels simultaneously.


  7. It is because of the way DAQFactory optimizes the graph data on large data sets.  It does a boxcar min/max and as new data comes in the boxcar locations change causing those mins/maxs to change slightly, especially at edges like when no data is coming in.  This can make the connecting line jump around.  Normally you can't see it because its only one pixel.


  8. Yes, that is the right direction, but you almost certainly will need either a carriage return or a carriage return / line feed afterwards.  I typically like to do it with a variable, or you can just add the chr() commands to the end.

    private string CRLF = chr(13) + chr(10)

    device.gsmmodem.write("+CMGS" + crlf)

    ...

     


  9. There isn't a cache, but if you edit a sequence that is running, you have to stop the sequence and restart it to pick up the changes.  If that isn't it, I'd have to see the rest of the code to know what is happening.  You might have a symbol name conflict (i.e. a private or global variable with the same name as one of your channels.)


  10. OK, this is the line that checks the condition:

    if ((Pressure[0] > 80) && (Pressure[1] <= 80))

    To check for it to be over 80 for over 10 minutes you'd do instead:

    if ((Pressure[systime(), systime() - 600] > 80))

    The problem is not sending emails over and over again so you'd have to add some logic to prevent that.  It could be to repeated send every so often if the alarm state is maintained, or to only set if reset.  This is actually what the Alarming feature of DAQFactory makes easy.


  11. That would largely depend on the HMI.  That particular one has 3 serial ports, so if one wasn't in use you could connect that to the PC and communicate with DAQFactory over that connection.  But that is just the hardware layer.  The real question is what protocol does the HMI speak?  I couldn't find it on their website.  If it talks Modbus, you could setup DAQFactory as a Modbus master or Modbus slave (depending on which license of DAQFactory you have) and transfer that way.  That would be easiest, especially if the HMI can act as a Modbus Slave and DAQFactory can be the Modbus master.

  12. Sure.  Use a Conversion on the channel.  You can either hard code the 5 values into each Conversion, or use variables that you then persist to disk using one of a variety of methods.  Which method to use depends largely on exactly how many total values you expect to persist.  The easiest way is to create a Test D to A channel for each value with a History of 1 and a Persist of 1.  But if there are a lot of values to store, you'd be better off using the File. functions to store them to a flat file.  Of course if you are using the program internally using a development version of DAQFactory and don't need to change them often, you can just put the values directly into the Conversions.


  13. I checked and the DAQConnect SSL cert is valid.  It was actually just updated in February and doesn't expire for several years.  So, something changed on your Windows setup that invalidated the certificate authority.  You may have to add the authority manually.  Open DAQConnect.com in a browser, then view it's certificate and the CA associated with it, then add the CA to your store as valid.  You may have to search the web for the details on how to do this for your particular version of Windows.  

    FYI: a certificate authority is a central, globally trusted site that your system contacts to verify that the DAQConnect cert is valid.  Its kind of like a tree.  I'm saying that I'm DAQConnect (my SSL) and you can ask the mayor (the CA) to confirm that.  The mayor says he's the mayor, and you can ask the state governor (the CA's CA) to confirm that.  The governor says he's the governor and you can ask the king to confirm that.  The king is know by everyone so doesn't need confirmation (or it is done a different way: outside my pay grade on how they confirm that).  Different website's SSL certs will have different paths to the king, and there are actually more than one king.  In your case, your system is telling you it thinks that the mayor is invalid or corrupt, so you need to tell it that the mayor is actually the mayor.

     


  14. Exactly that.  Delete the file pegrc32a.dll and copy pegrp32a.dll to pegrc32a.dll so you end up with two files, pegrc32a.dll and pegrp32a.dll that are the same, and the same as the original pegrp32a.dll.

     


  15. We are talking about two different things.  It just happens that you named them both the same thing.  In DAQFactory, there are comm devices that you create and give a name.  This name is what shows up in the Channel table, and you used "TouchPro".  But a comm device is made up of two things, a port (serial or ethernet) and a protocol.  This allows you to use a single port on separate devices (useful for those using radio modems) among other things.  In your case, you have the one device, but you created two ethernet port connections to the same IP, named "TouchPro" and "Ethernet".  The quickest way to see this is to go Quick - Device Configuration, then select your TouchPro device.  Then you will see in the serial/ethernet configuration window that those two "ports".

     


  16. You are talking about Modbus Master?  Then yes, it doesn't matter.  The ports are handled by the remote device.  192.168.0.1 port 502 and 192.168.0.1 port 503 are two completely different connection points so are no different than 192.168.0.1 port 502 and 192.168.0.56 port 502.  To connect to a device you need the IP and the port.  Any changes in either of these are a different connection, even though a change of port is still the same device.

    I like to think of it like a telephone to an office building.  The IP address gets you to the main office line, and the port # is the extension.  So calling the telephone number (IP address) gets you to the right building (device), but you also need to know the extension (port) of the person (protocol) you want to talk to.  If your device has both 502 and 503 open and available to receive calls (sockets), then DAQFactory can certainly connect to both simultaneously using two different DAQFactory "ports" and "devices".

     


  17. OK, glad you sent it.  You actually have two Ports in your application, even though presumably only one is assigned to a device.  You have one called "Ethernet", and one called "TOUCHPRO".  Both point to the same device, same place.  This is apparently causing an issue, probably because DAQFactory tries to establish both connections simultaneously on startup and your device can't handle it, but if you disconnect and reconnect, DAQFactory staggers the reconnection.  Or it just never reconnects the one that isn't used.  Either way, if you delete the connection you aren't using, or at least set the IP to blank and the Port to 0, the probably will likely go away.

    On a side note, 200.200.200.190 is a routable address and so should not be used for internal networking.  Use something in the 192.168.x.x, 10.x.x.x or 172.16-31.x.x subnets, as these ranges are non-routable addresses and won't be confused for Internet addresses by Windows.  If you don't then when Windows (and thus DAQFactory) can't find the device at 200.200.200.190, it will go to your gateway router and then through it, up into the Internet looking for a device at 200.200.200.190, which appears to be somewhere in Brazil...

    If you actually meant to use a routable address, don't.  There are huge security issues with placing an automation device directly on the Internet.

     


  18. I meant more than one device / software connected to the remote device.  Does it do it from a fresh boot?

    Does the Ethernet comms light light up when the ethernet is plugged in but DAQFactory won't communicate?

    Does your remote device use DHCP to get its IP address?