patrickokeeffe

Yes the double control panels is just terrible. That was my first thought! Unicode vs. non-unicode could also make sense. 

I need to use the ISO8601 style regardless so not a big deal to just set the format explicitly. Too bad %c doesn't work though, might be worth noting up front in the guide.

`FormatDateTime("%c", ...)` should produce a date and time represented using Window's locale settings, but version 19.1 (b2366) on Windows 10 seems to ignore Windows settings and produce dates using MM/DD/YY regardless. I first noticed the discrepancy in my logging set file time column. Note the difference in configured date/time format versus function result: 

The old Windows 7-style regional settings are still available and confirm the settings shown in the new dialog. 

Yes the application appears to working great so I didn't expect the process to hang. One change I made around the same time it started hanging on exit was to add a ModbusTCP device to the control document (with 1 sec timeout, 5 second query rate). The document already had two serial devices using user-defined protocols and two serial devices using null protocol + dedicated sequences. It had been running without issue for weeks at a time. Adding the Modbus device is the only real change I can recall making. 

I did not think to switch into safe mode before exiting but I will keep that in mind in case I see this again.  

I'm using version 19.1 on Windows 10 Enterprise, running it with Administrative rights. I have a problem recently with the daqfactory.exe process not exiting, it just hangs around doing nothing until I manually kill it. I've analyzed the wait chain using Task Manager and sometimes it reports "One or more threads are waiting on network I/O" other times it reports "DAQFactory is running normally". However, I've left it alone overnight and the process never manages to resolve itself, it just stays a zombie. Can I fix this somehow so that DAQFactory cleanly exits? 

I am avoiding this issue by doing all of my editing outside of DAQFactory. Just wanted to report it's still present in more current versions. Thanks

I'm working on moving a control program from one computer to another and while checking our custom protocol (.ddp) files I noticed the `Poll` function that's provided as part of the template has been copied into the `OnSend` event. Two examples are attached. 

I recall this being a problem with earlier versions but these protocol files were written with fairly new DAQFactory versions - either 18.1 or 19.1. 

n2OAnalyzer.ddp

CH4Analyzer.ddp

I didn't reboot the computer or power cycle the UE9. I also didn't modify the old control document, just loaded the saved file. I did completely close DAQFactory when I changed the U12 addresses but in the past just restarting DAQFactory hadn't been enough to fix it. I also observed the 'control' LED on the UE9 began flashing after I disconnected the U12 units and that seemed like a new thing to be happening but, like you say, they don't use the same drivers and should be unrelated, so I brushed it off as coincidence.

Remember when GM snapped back at Bill Gates over his auto industry comparison? "If GM developed technology like Microsoft then occasionally your car would just die on the motorway for no reason, You would have to pull over to the side of the road, close all of the car windows, shut it off, restart it, and reopen the windows before you could continue. For some reason you would simply accept this, restart and drive on." There's a whole bunch more like that and they were all pretty funny.

So good news and strange news. I disconnected the U12 LabJacks, setup a new document, and had no problems communicating with the UE9. I tested with an analog input and data looked great. Then I took the downtime opportunity to set a unique address on the U12 that had been using 0 and when I loaded my original document, the communication errors with the UE9 were no longer present. I'm not sure how to interpret the effect of fixing the U12 address on the UE9 but things are working again and I'll keep it in mind next time I see a Labjack without a unique ID.

22 hours ago, AzeoTech said:

1) how are you powering the UE9?  Is it connected via USB?  Was it ever connected via USB while DAQFactory was running.

Good question. It's powered with a separate DC transformer (I don't recall what voltage). The UE9 was setup as Ethernet originally and it's far enough away I don't think anyone plugged it in via USB. 

22 hours ago, AzeoTech said:

2) You don't want to use localID 0 for any LabJack.  That means "FirstFound" in DAQFactory.  They are U12's, so won't interfere with the UE9, but still...

Yes I realized that when I was verifying their addresses but since it's a live system I'll have to wait to fix it. 

22 hours ago, AzeoTech said:

3) can you post the raw settings for the device configuration?  Click on Quick - Device Configuration, select LabJack UD, then instead of clicking ok, click View Raw.  Copy and paste the contents here.

Here's the raw view text and a screenshot. I attached the .ctl file as well. 

2,UE9,Ethernet,192.168.3.13

PilotPLant_May2022.ctl

I'm observing problems communicating with a Labjack UE9 using DAQFactory 19.1 b2366 on Windows 10 Enterprise x64. Specifically I get this message once per second (timing is 1):

D0050:02:1007 LabJack Device #2 error: LabJack not found

The LabJack is configured for DHCP and receives a static IP reservation from my router. The device Local ID was set to 2 using LJControlPanel and firmware is confirmed to be up-to-date.

DAQFactory has a firewall exception and is allowed to communicate with network devices. I added the LabJack using Quick - Device Configuration (choosing LabJackUD instead of LabJack since the latter is not a real option in DF19.1). I also assigned it to Device Number 2 to keep things simple (App Guide doesn't say anything disallows this, just that the Device Number not Local ID should be referenced in channel setup). 

I then created a test analog input channel as described in the LabJack App Guide (again using LabJackUD since LabJack is no longer a real option). 

There is some data in my test channel but it looks like random garbage, and the LabJack not found errors persist even after power cycling the LabJack and after restarting DAQFactory. 

Any ideas as to what's going on here? 

[EDIT]:

Yes I have other LabJack devices connected via USB - two U12 units and neither one is using device Local ID 2:

So I rearranged my try-catch block to wrap the entire script:

while (1)
   try
      msg = Device.AIRMAR_200WX.ReadUntil(CHR(10))

      if (Compare(Left(msg,1),"$"))
         continue // skip partial message
      endif
      // WARNING message checksum will be discarded without use

      msgid = Mid(msg,1,5) // defer data parsing until matching header is found
      switch
         //
         // ... lots of code removed ...
         //
      endcase

   catch ("C1136")
      ? "Caught serial comm error: " + strLastError
      delay(5)
      Device.AIRMAR_200WX.Purge()
      Device.AIRMAR_200WX.InitComm()
      //continue
   endcatch

   catch ()
      ? "Ignoring error: " + strLastError
   endcatch
endwhile

With the second continue statement enabled, the sequence halts but without it, the loop keeps running until the comm error is resolved. Something about the catch block turns the continue into a break instead. 

The help for while loops (section 5.14) says this about continue:

Quote

The continue statement causes the sequence to jump back to the while statement, reevaluate the condition and either start the loop over, or break out of it

It works as expected inside an if block (the second instance which discards partial messages) but inside the catch block it behaves funny. When serial comms fail, my command window should be littered with these two messages but instead they print once each and the sequence ends. 

So far I just added debug statements to help determine where the loop ends when it catches an error. I think it does make sense though to relocate the try-catch so it contains the whole script.

Does try...catch do something undocumented regarding continue? I've been debugging the sequence below and the whole sequence halts anytime it hits catch(), instead of continue'ing as I had expected. It doesn't ever reach the 3rd print statement (after the continue) but it does fail to continue the while loop. My alert window shows these two messages and the sequence gets ended.

Quote

Ignoring error: C1136 Timeout: read_200wx_nmea0183 Line 34
finished delaying... next while loop

I'm using DF 18.1 bld 2347 on Windows 10 Enterprise, with 'Run as administrator' compatibility mode enabled. I'm not using ignore(..) because I plan to re-initialize comms if C1136 occurs.

(the try-catch block is my attempt to resolve this issue that's cropping up again: serial data streams cut out after indeterminate length of time and require reinitialization through the configuration menu)

Auto-start sequence named "read_200wx_nmea0183":

private string msg
private string msgid
private string vals
private v1
private v2

while (1)
   try
      msg = Device.AIRMAR_200WX.ReadUntil(CHR(10))
   catch ()//"C1136")
      ? "Ignoring error: " + strLastError
      delay(0.5)
      ? "finished delaying... next while loop"
      continue
      ? "should never reach here, after continue"
   endcatch

   if (Compare(Left(msg,1),"$"))
      continue // skip partial message
   endif
   // WARNING message checksum will be discarded without use

   msgid = Mid(msg,1,5) // defer data parsing until matching header is found
   switch
      //
      // ... lots of code removed ...
      //
   endcase
endwhile

Sorry I misunderstood your reply at first: I was observing serial data streams continuing to be parsed, unrelated to the labjack. I've since moved to newer DAQFactory versions and hopefully it's not a problem anymore. Thanks

Quote

I've been saying for many, many years that people should avoid USB -> serial devices and use Ethernet->Serial if they want true reliability.

This is an old thread, but it's worth pointing out an NPort virtual com port is an Ethernet->Serial connection. If you meant creating a TCP (Ethernet) port instead of an RS232/422/428 (Serial) port inside DAQFactory, that could have been expressed more clearly. 

The data is separate channels right now:

* Latitude
* Longitude
* Some environmental scalar (e.g. gas concentration or temperature)

I anticipate 1Hz sampling so if we plot the most recent half-hour (typical) it'd be 1800 rows. 

I can emulate this plot using 2D graph component. Would be nice to have the color scale legend but it doesn't seem to have an option for display.

[output_38_1.png]

I'd like to underlay a map image like in this plot. If 2D graph were transparent I would just paste a screenshot. The User Guide says Image will handle 2D data but I tried and saw the data should actually be a 3D array. So I'm not sure if this is actually possible in DF.

[output_40_1.png]

Just example images, btw. The data I want to plot would be contained in a relatively small area, less than a square mile, hence the desire for satellite imagery views.

Agreed, I do the normalization in the color expression and have a global variable that defines the normalized range maximum. Having script access to the color table builder will make this approach much more efficient and doable - thanks for the heads up. 

Could I use an Image component instead of 2D graph? Plotting line features on a 2D graph is straightforward if the data is well-formatted, but transforming GIS data into that format is not trivial. I am more interested in placing satellite imagery underneath anyway, versus showing line features. 

OK thanks - I'll wait for the patch and try again with 3D later. I'd like it for experimenting with plotting multiple variables. For now I have a single variable plotted 2D and works pretty OK. There's two big challenges I encountered and could use advice on.

The first is the color selector: it's made of discrete thresholds (versus, for example, assigning a gradient to span a range set by two values). We want to adjust color scales quickly as ambient conditions change or we swap in different variables of interest. The best approach I found was to assign thresholds from 0 to 1 and then normalize the plotted variable by the desired maximum range value. It's clunky but faster than editing thresholds. Perhaps there's a better approach?

My other challenge is to underlay a static image from Google Earth. I might try it as a screen component underneath the plot at first. Ideally though the lat/long (x/y) ranges chosen for the 2D plot would be used to align the image. Not sure that's possible with a 2D graph though.

Can anyone share a good example of the 3D graph component? I tried putting some example arrays into the Expression field just to get started, but the graph component remains completely blank. None of the options seem to have any effect either. 

{1,2,3,4} // 1D array
{{1,2},{3,4}} // 2D array
{{{1,2},{3,4}},{{5,6},{7,8}}} // 3D array
{{{1,2,10,20},{3,4,11,21}},{{5,6,12,22},{7,8,13,23}}} // another 3D
{{{1,2},{3,4},{10,11},{15,16}},{{5,6},{7,8},{12,13},{17,18}}} // and another

I'm looking to scatter plot scalar data (vertical axis) vs. lat/long coordinates (horizontal plane). My data is in separate channels right now. My DF version is 18.1 build 2347

OK yes that will work fine. Thank you!

I'm working in DF18 and reading the DF17.1 user manual. Feeling a little silly I can't find any rounding-related functions except for "CEIL" and "FLOOR". Is there really no function for nearest number rounding? I have to compute the nearest integer instead?

Thanks for the suggestion. I'm actually seeing this several different serial ports:

* With my USB-RS485 converter, it's 100% reproducible
* Using NPort virtual com port drivers, the issue occurs roughly 1 in 3 times I click-through the configuration screen
* still TBD: whether or not this issue occurs in relation to a physical RS232 port

What I don't understand is why the initialization routine would de-initialize a port (what it seems is happening in this situation).

I've been using version 18.1 and see strange behavior related to serial ports. Immediately after creating a new serial port with the correct port parameters, I see no traffic on that port. However, once I open the port configuration screen and press Save to close, traffic immediately appears. Nothing actually needs to be modified on the configuration screen, it just needs to be opened and closed. 

This behavior was observed when setting up three different serial devices, and it's reproducible for me too:

1. Open Comm Monitor for port in question (COM7 in this case, assume there is already traffic flowing)
2. Right-click and choose Configure... 
3. Do nothing and press Save to close the window
4. Observe traffic has stopped
5. Right-click and choose Configure... 
6. Do nothing and press Save to close the window
7. Observe traffic flowing again
8. Repeat again and again

I saved a copy of the control document in both states:

* with traffic flowing: `compostpile-msmts.ctl`
* with traffic stalled: `compostpile-msmts(stalled).ctl`

Here is my full environment:

* DAQFactory 18.1, Base Release, build 2347
* Windows 10 Enterprise running as administrative user
* COM 1-6 are physical ports not in use
* COM7 is an Airmar brand RS485-usb serial adapter
    * port settings: 4800/8n1, 1000ms timeout, no flow control
    * sends several NMEA0183 compliant streams
* other 2 COM ports are virtual comport drivers linked to an nport 5610-8-DT serial port server

compostpile-msmts.ctl

compostpile-msmts(stalled).ctl

Related?