AzeoTech

Yes, that is the bug mentioned in the post.  You can't use the right-click graph capture feature in newer OS's.  You'll have to use an alternative such as the printPDF function.

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)

...

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.)

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.

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.

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.

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.

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".

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".

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.

Please post or email your .ctl doc so I can take a look.  If its reading data on the one channel, then there must be some other connection inside your document.

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?

Channels look just like variables with some exceptions.  So, if you have a digital output channel called "LED", you could have a sequence like this:

LED = 1
delay(5)
LED = 0

Alarms with expressions that are invalid won't trigger, nor will they generate an alert, so you should be fine.

Are you sure you don't have another piece of software or another device communicating with device?  Many devices support only one connection at a time.  Disconnecting and reconnecting would drop an existing connection and give DAQFactory a chance to connect.

To avoid bogging down your system by accidentally specifying a big array, DAQFactory will only display the first 20 values in any array.  So if you do:

myChannel

instead of 

myChannel[0]

you'll only get the first 20 values of myChannel, not the entire history, which would chew up a lot of CPU time to display, over and over again.

So, you are running up against this.  What you'll have to do is display two sets of 16:

(To.Bit(x))[0][0,15] 

and

(To.Bit(x))[0][16,31]

First, does the error keep reappearing, or is it simply left over from when the cable was unplugged?  Errors in the command/alert don't go away unless you explicitly clear the command/alert window by right clicking and selecting Clear.

Nope.  That would defeat the purpose of the licensing mechanism.  As the docs say:

"Do not lose your password!  We cannot recover it for you!  If you lose the password you will not be able to use your application on systems that aren't otherwise licensed and you won't be able to install your application on any new computers.  Once again, while we can recover document editing passwords for a fee and subject to proof that you created the document, we CANNOT recover the licensing password for you as there is no way for you to prove to us that you are the owner of the document other than knowing this password.  That all said, we do offer a document registration service.  You provide us with your document before you enable the license feature, or at least before you have forgotten the licensing password, along with the emails of people authorized to retrieve the password, and in the case of a lost password, we can retrieve it for these individuals or the president / owner of the company it is registered to.  There is a fee for this service and for any password recovery.  We have to have your document ahead of time to retrieve an internal unique identifier.  This identifier stays with your document even after you edit it and is what gets registered with the recovery email addresses.  Please contact us to set this up."

For the U series devices there is the DAQFactory - LabJack Application Guide which is installed with DAQFactory.  This covers most everything you need to know.  To control an output, you just need to create a Channel in DAQFactory with device type Dig Out.  DAQFactory will switch the pin direction for you in this case.

That is still pretty odd.  Does that number actually update?  Try creating a variable value control with this Expression:

CH1.time[0]

and see if it changes as well.

It is hard to say.  It is probably just one channel that is causing it.  Either you are querying an invalid tag, or you have other settings wrong on one of your channels, such as D# set to 0 instead of the proper Modbus ID.  I would go through and set the Timing of all your channels to 0, then reset them one by one until the message starts appearing.  Then you'll know which channel is causing the troubles.  

There's nothing glaringly wrong in your document, though you should watch your indentation.  Though that won't affect the way DAQFactory, it does affect how readable your code is.

(S1 & 0x0f) == 0

((S1 & 0x0f) < 8) && ((S1 & 0x0f) > 0)

max(S & 0x0f) == 0

min(((S & 0x0f) < 8) && ((S & 0x0f) > 0)) == 1

OK, keep us informed.

Sorry, did you send me the ctl doc?  Its been 6 months so could you send it again?