AzeoTech

To confirm that it was removed, just run DAQFactory and see if a trial dialog appears.  If it does, then there is no license.

It is giving you the other message because the upgrade key only works if you have the appropriate license already installed.  For example, if you are upgrading from Lite to Base, the key only works if you have Lite installed and licensed.  Otherwise folks would just buy the upgrade key and get Base for half price.  If you have troubles with your keys, contact us directly.

The 15-16 letter key was emailed to you when you purchased.  You need to use that key.  It is not stored with the installation (otherwise someone could easily steal your license!).  

You can get the new computer working first if you like, then remove the development license off the old computer.

OK.  I still recommend upgrading...  You are missing out on a lot.  Just backup your document before doing so.  Then you could revert back to 5.87c if you really wanted to.

Your release is ancient (by software standards).  Like over 13 years old.  As such I can't really address any issues with it.  You really should upgrade, at least to 19.1, probably to 20.2, especially if you are creating a new document.  There is no charge for the upgrade to the newer release.

I'm assuming you called your sequence "LampCheck" too.

I'm not sure and would need more detail on your application and what exactly makes you think it is failing.  I made a simple equivalent sample (release 19.1) that I've attached here that shows it working as expected, both in 19.1 and 20.2.

sequenceCaller.ctl

There are two errors:

1) the primary error is that you are mixing C/C++ syntax with DAQFactory.  DAQFactory only uses {} for denoting a static array.  It is not used for blocks like it is in C.  So, you want something like:

function LampToggle(Light)
   // code
endfunction

function LampCurrentMonitor()
   // more code
endfunction

2) while you can put multiple functions in a single sequence, the first function MUST have the same name as sequence.  Actually it doesn't, but the name you provide for the sequence is the one the first function gets.  So if the code you posted (with the changes mentioned above for endfunction) was in a sequence called myFunctions, you would be able to call LampCurrentMonitor() fine, but LampToggle() would not work.  It would be named myFunctions() as far as DAQFactory is concerned because that is what you named the sequence.

Thanks.  We are aware of that issue.  It is a bug in the tool we use to generate the help system when used in an embedded browser.  For now, I would recommend opening the PDF form of the help, installed in the DAQFactory installation folder, and do a search there.

Thank you for the input.  The difference here is that the devices themselves, the LabJack and serial device, are not in safe mode.  Safe mode in this case is a DAQFactory feature.  Since streaming data, both from the LabJack and from asynchronous serial devices is controlled by the device and not DAQFactory, switching DAQFactory does not stop the data from coming in.

Safe mode in DAQFactory is largely designed to allow someone to load a document into a computer that does not have hardware and avoid all the errors that would be generated.  It is also designed to allow someone to load a document of unknown origin and check it for potential harmful script.  Safe mode in DAQFactory blocks outgoing serial comms, all the file based functions, and most scripts among other things.  Although it is called "mode", it is not really a mode that one typically switches into an out of.  Typically one will load a file in safe mode and work with it in safe mode, possibly coming out of it when hardware becomes available.  A working system is not typically switched into DAQFactory safe mode otherwise.

Thanks!  Yet another reason to avoid USB...

Yup, it was a very simple fix which has been applied.  If you'd like to email us at support@ I can get you a link to an update.  Otherwise it will probably be a couple days before we release it as 20.3.

Thank you again for your detailed bug report.

Excellent information and debugging.  We should be able to resolve this quick.  In the meantime, if the issue is auto-hide with the help, you can reset the help window back to its default by quitting DAQFactory, then opening the registry editor, navigating to HKEY_LOCAL_MACHINE/Software/DAQFactory/DAQFactory (yes two DAQFactory's) and delete the entire subfolder "BCGWorkspace20".  If there is a "BCGWorkspace2" you can delete that as well.

Thank you for the bug report.  Can you tell me what folder you installed DAQFactory into?  Also, how are you starting DAQFactory?

You may be able to switch off the Auto-grid mode for the bottom axis and play around with the settings.

A couple of key notes before I start:

1) hexadecimal is a loaded term.  Hexadecimal is just another way of representing a number.  So, 15 (base 10 / decimal) and 0x0F (base 16 / hex) are the exact same number and you can use either in DAQFactory IF, and that's a big IF, the device actually wants numbers (i.e. binary) and not an ASCII representation of numbers.  If it wants an ASCII representation then the ASCII string "15" and the ASCII string "0F" are not the same and you have to use "0F".

2) the \ notation, i.e. \x0F only works in the comm monitor.  It does not work in the write() function and therefore it won't work in the poll() function (which uses write).  You instead have to build up your string using chr(), or chra()

Besides those two points I can't say more without seeing the documentation to know if the device expects numbers or ASCII representations of numbers.  If you can type

\x02\x81\xD4\xD5\x03

in the comm monitor and get the desired result, then it expects numbers and is binary protocol.

I will also say this: user protocols are probably being deprecated (and don't work in 20.1+) and therefore I suggest writing sequences to perform the polling instead.  You can copy the poll() function if you want to help you, though you will have to specify the full device name for functions like write(), readUntil(), and purge().  It is also much easier to debug in a sequence.

Can you post a sample of the result and a screen shot of the export set.

That appears to be a bug in 20.1.  It has been fixed and will be so in the next release.  Thank you for the report.

Now that we finally have 20.1 out I expect we will do rapid releases, maybe once a month.  The next one should be within a week.  It will likely be numbered 20.11 and it will include access to the PID integral sum under the variable "IntSum".  It is read/write.

We will look to add that in the next release (20.2).  It should be quite easy for us to do.

You can use the PID's event to manage the loop.  See section 10.4 for more detail.  You can't change the actual accumulated I parameter from script.  You could, however, set the IntLimit parameter to, say, 1e-9 for an iteration or two after starting and that should essentially reset the accumulated I.  Also note that Reset on SP change will cause the accumulated I to reset whenever the SP changes.  You can just tweak the SP by a very small amount and it will reset the accumulated I.  Of course Reset on Start will do this as well whenever you start the PID loop.

ShellExecute() creates a completely separate process, and there really aren't easy ways in Windows for processes to communicate with each other.  Windows does this for good reasons.  If you are writing your own code, it is usually best to create a DLL that DAQFactory can link to using extern() instead of an Exe it has to run.  A DLL runs in the DAQFactory process, so DAQFactory will wait for a response.  With ShellExecute() it is completely fire and forget.  Really your only alternative is to use a file or some other normal interprocess communication technique such as sockets, so while it seems it isn't very elegant, it is unfortunately the only choice.  (actually you could also search for the other processes window, but that gets into the real nitty gritty of Windows).   This limitation would be true basically with any application, not just DAQFactory.  It is why there are DLLs.

Yes, by giving each set of channels for a single PLC different Timing/Offset combinations it will poll each PLC in a separate thread and so won't interfere with each other.

If you have multiple PLC's that are on different IP addresses and not on a single RS485 chain, you can simply give all the channels of each PLC a different Timing/Offset combination.  This will cause DAQFactory to query them simultaneously, and timeouts caused by one PLC being offline won't affect the others.  So, for example, PLC1 might have its channels on Timing 1, Offset 0, while PLC2 might have Timing 1, Offset 0.25, and PLC3 might have Timing 1, Offset 0.5.

As for device bypass, it is likely that you created circular logic and blew the stack.  I'd have to see your document to truly tell.  

Can you provide a little more detail on your use case?

I asked because you should replace the endseq(S3) with just return:

  if (AutoCycleRunning == 0)
      delay(1)
      db.Close(dbase)
      return
   endif

There is no reason to tell a sequence to stop itself using endseq()

I'm sorry but I don't know Excel well enough to advise on that.  There are a lot of security implications as well for doing such a thing.  Word and Excel a long time ago started restricting running macros.