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.

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

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.