gkimsey

Members
  • Content Count

    25
  • Joined

  • Last visited

Everything posted by gkimsey

  1. I'm having trouble in my project when reading some channels in a sequence at load time. The Channels are set up, but none of the A to D channels are set to read automatically (I just want to read at specific times). Basically when my init sequence runs I get an error such as "Request made on pin not properly configured for analog/digital". The sequence contains about half a dozen Read() commands on various inputs and an assortment of digital output settings. Now, since the initialization sequence failed I'll restart it manually, and get similar results but it gets a few commands further before giving an error. I'll do it again, and everything seems to go fine but one of my digital outputs is in the wrong state (always the same one). Then, running it a 4th or 5th time, everything goes fine. This only happens when the LabJack hasn't been used since being plugged in (i.e. I can restart the whole project after it works and it'll work the first time). The biggest problem I have is that I can't even catch all of these issues with OnAlert (to fully automate the retry process). On the last time through an output is in the wrong state so I get no alert. Why does it take so many attempts to get this working? I have a debug/testing project I set up with the same Channel list as my main project. This other one DOES automatically poll certain channels. When I plug in the LabJack while it's running I get the similar "Request made on pin not properly configured for analog/digital" errors for several reads before they go away. The issue seems to be based on the number of attempted reads rather than real time. I.e. in the first example if I wait a full minute between retries it still takes 4 or 5 times through my init sequence. If the failed reads aren't something I can fix altogether, I need some way to programmatically get to the point where all my I/Os operate as expected, and to know for sure that I'm there.
  2. gkimsey

    Unable To Load Dll (Custom Dll)

    Absolutely correct -- thanks! C++ runtimes weren't my only problem, but they were the biggest one. For the next person with this problem: I got a bit of a red herring from the Dependency Walker because it complained of mismatched CPU types on modules. Apparently you should use the x86 version of Dependency Walker when looking at a 32-bit DLL (even when on a 64-bit system), or this type of thing happens. Thanks again for getting me out of DLL hell!
  3. I'm trying to load a DLL using extern(). This is a known good DLL as I have this same project running on 3 systems (one Win7, two Win8) without issue. For some reason I get the "Unable to load DLL" error on this 4th system. At first I thought I might have some permissions / UAC issue, as that's bit me before on a new PC, but I disabled UAC, installed as administrator, ran as administrator, and even tried the XP compatibility mode to no avail. The file path is OK, because I can copy and paste the path it says it couldn't load ("C:\Users\..\..\myDll.dll") into a Run... dialog such as "notepad [path]" and it'll pull it up. Any ideas? Clearly this has to do with file paths or permissions somehow but without more information than "unable to load" I'm having a hard time narrowing it down. My next step is to dig up the Visual C++ solution for the DLL and run it in debug mode, but that's a lot of installation and setup that has a decent chance of ending in VC++ never getting called at all, which won't tell me much. I'm also going to try a simple version of the load in a different project with an easy file path and see what that gets me. Taking all suggestions here. Thanks.
  4. See the attached test project. By running the RegistryWrite sequence and then the RegistryRead sequence, "Registry Test" should appear in the Alert window. Works for me on Windows 7 but not on Windows 8. I'm running as administrator on both. Can you guys replicate this? regtest.ctl
  5. I'm using the tree list component extensively in my project. I have just discovered that if the list is long enough to make a vertical scroll bar, that scroll bar behaves strangely towards the bottom of the list. I've attached a sample project which sort of replicates my main problem. The tree is filled by the auto-start sequence. Scroll down so that item 16 is the one shown at the bottom of the list. Then try to scroll further down with the down arrow. It doesn't work and stays in the middle. In this sample, you can sort of get past it by dragging the scroll bar, but in my project I run into cases where that's not a possible workaround. While I'm on the tree list, is there any chance of getting a single click event or a function that allows me to programmatically set the selected item (and highlight accordingly)? Or a function that will retrieve the item handle from an index? (As it stands, for instance, I have no way to reorganize the default tree elements because I can't get their handles, so I'm forced to clear the tree every time unless I saved everything off from InsertItem calls) tree-list-problem.ctl
  6. Sure enough, that was it. Thanks. Not sure why I would name it that way -- just confusing myself.
  7. I get the error: "Unable to initialize Com9: Can't access port, probably in use by another app" But I'm no longer trying to use a serial port (I was a long time ago when working on this project). I'm not sure where the error is coming from (or rather, why DAQFactory is trying ot initialize Com9 at all). Under "Device Configuration..." I don't see any custom device I created. When in safe mode if I do "Delete Comm Device..." there's nothing in the list. Where else should I look? Typically in these situations I would crack open a project's XML or configuration file and search for "com9" but it doesn't looke like I can do that with .CTL files. Another topic sort of talks about this here, but it's regarding how to keep the error message from showing up when legitimately using a COM port, which I'm not (or don't want to be). http://www.azeotech.com/board/index.php?/topic/4366-how-to-avoid-error-message/page__hl__%2Bcan%26%2339%3Bt+%2Baccess+%2Bport
  8. While trying to recover from the issue in this thread: http://www.azeotech.com/board/index.php?/topic/4886-channels-were-deleted-after-open-in-trial-mode/page__hl__+trial%20+version#entry17127 I exported (working) LabJack channels from a backup project and imported them into the main one. The list gets populated correctly and everything looks fine, but when read the A to D channels show an integer value. Looks like the automatic conversion to floating point volts isn't happening. If I add the channels one at a time manually they behave normally, so that will work for the time being. Attached is the channel export and a screenshot of the table. (renamed the channels to .txt to allow upload) lt-channels.txt
  9. I just had a similar issue. I was editing sequences on my main project, and unknowingly didn't have the hard key installed, but I didn't get the message to re-insert it. Obviously I was saving the project occasionally as I made edits. When I reloaded the project, all but 10 of my channel definitions were gone. There wasn't any warning about the license. I only noticed it because when I finished my sequence edits I saw a bunch of disabled UI elements on one of my pages. Luckily I have a backup file with the channel list so I'll export/import that, but I'm worried I lost something else or something I changed since making the backup. v5.87a Build 1972
  10. Okay, sounds good. I'm actively working on it right now and can't merge changes easily so I'll send it along as soon as I can. Thanks!
  11. Okay, found the problem. Short answer: You were right, permissions issue. Background for the next person who runs into this: I discovered that DAQFactory was writing the registry variables to a virtualized registry location, but Windows apparently wasn't redirecting it there for the subsequent "read" (because it failed to read it back). Turns out it was doing this because I didn't properly install DAQFactory as an administrator. This is one of those Windows Vista-and-later gotchas related to User Account Control (UAC). Even if you're an admin, if you don't right-click and use "Run as Administrator" AND you still have UAC enabled, you're not "really" running as an administrator. This results in DAQFactory.exe being installed with reduced permissions, which subsequently means it doesn't access the registry the same way. So the solution is easy: Reinstall with admin privileges. Two suggestions for DAQFactory updates: 1) This can't be an unusual problem. I didn't have the issue on my Windows 7 machine because I had UAC turned off before I installed DAQFactory, but this probably can't be relied upon. Maybe the installer can verify full admin permissions before allowing the install to go forward. It does say "must be installed by an administrator," but that was technically true when I encountered the problem. 2) In order for the "virtualized registry" to have worked for writing the registry entry but NOT for reading it, it seems like there may be some discrepancy between them internally. Maybe some older/newer APIs being mixed or something.
  12. OK, so there's not a way to flush it out of the project file? When it's just me using the project I can easily enough ignore the error, but other users will be confused by it and think something is genuinely wrong. Can I catch or hide it some way?
  13. I've run into a problem related to export sets and DLLs. Basically, if I export a certain way after opening a project, then try to call a DLL which writes to a (different) file, the DLL write doesn't work. In fact, lots of other problems arise in DLLs because of this, not just the file writes, but that's the easiest thing to verify. If, however, I simply call the DLL function, it runs and creates the file fine. Only if I export BEFORE calling the function does the problem arise. Again, the files are unrelated. The DLL is not writing to the same file that the export set is writing to. I've attached a very small project which shows this, including a tiny DLL with one function that just writes some text to a file. The project automatically loads the DLL. To see the problem, manually type the following two commands into the Command / Alert window: beginexport(DebugExportSet) fnSimpleDLL() [/CODE] This has to be done RIGHT AFTER OPENING THE CTL. If fnSimpleDLL() was run successfully already, the export doesn't seem to cause a problem for subsequent calls. I included a sequence that shows this, but don't run it directly because somehow the timing of it means it doesn't always show the behavior. To test that fnSimpleDLL() actually does something, [b]close and reopen[/b] the project and just type: [CODE] fnSimpleDLL() [/CODE] You should see "simpledll.txt" show up in the project directory (assuming you double clicked it from explorer. Side note: It's weird that DAQFactory's working directory is different depending on how you open a file. Tough to work around). By the way the DebugExportSet exports to C:\debug.csv, and the specific settings of the export set MAY MATTER. I hope the procedure to reproduce the bug makes sense. I've verified this with two projects, different DLLs, different export sets, and different PCs. It's also holding me up on a much larger project so I'm hoping to get some feedback ASAP. In the meantime I'm trying to work around it by making sure I never export before running my DLL functions. Here's the code for the DLL's function: [CODE] extern "C" SIMPLEDLL_API int fnSimpleDLL(void) { FILE * outfile = fopen("simpledll.txt", "a"); fprintf(outfile, "Hello\n"); fclose(outfile); return 42; } [/CODE] DLLProblem.zip
  14. gkimsey

    Help! Strange Bug With Export + Dll File Write

    More updates: It occurred to me after typing up the last bit that on my Windows 7 machine I have the CTL file's directory added to the system PATH (which I'm convinced shouldn't be necessary, but apparently I'm wrong), and on the Windows 8 machine I didn't. Adding it fixed the crash with delayed load. Hope this helps somebody. I don't consider it a great solution but it's a way to force Windows to use its full search path.
  15. gkimsey

    Help! Strange Bug With Export + Dll File Write

    Update on this: The DELAYLOAD linker option is still working around the problem on Windows 7, but after moving to Windows 8 it causes a crash. I've verified that the error is that it can't find the module, and I'm fairly certain at this point that it's the delayed load causing a more catastrophic error (instead of DAQFactory catching the problem). Not sure how I'm going to get around this yet, but it all still goes back to DLLs not being found despite being in the same directory as the CTL file, so any ideas are welcome.
  16. I have a pretty straightforward File Save Dialog in a quick sequence. Code looks like this: private string fileName = file.FileSaveDialog(g_log_filename,"","*.csv","CSV Files")[/CODE] where g_log_filename is an existing global string containing the full path to a CSV file. But when the dialog comes up I don't see existing files with the CSV extension in the directories I'm working through. I thought the filter might be wrong, but "*.csv" is exactly what tooltip example has in it. How do I fix this? Also, at the bottom of the dialog where you can choose "Save as type..." from a dropdown, there is usually some random text from one of my scripts stuck in there somehow. I'm guessing the FileSaveDialog doesn't actually use the Save As Type, but it'd be better if it only showed *.csv. See attached screenshot. OS is Windows 7.
  17. gkimsey

    Help! Strange Bug With Export + Dll File Write

    OK, I think I've resolved the problem, or at least worked around it for the time being. Essentially I discovered that while my own DLL was being found, its own dependency DLLs couldn't be found. DAQFactory's error is ambiguous here, just saying the top level DLL couldn't be loaded (can you pass the WINAPI error instead or in addition?). At the time my DLL was loaded, the Path environment variable is either blank or just very wrong in one way or another. I have not found out who the culprit of this is (LabJack DLL or DAQFactory). Anyway, by using Delayed Loading of all the dependency DLLs (a linker option), I essentially deferred the file search to later on when my DLL's individual functions were actually called. At this time, the Path variable is "sane" and everything works fine. My current assumption that the Path is being screwed up still seems like a valid explanation for the problem that started this thread (export + file write) and the problem that I just resolved (Use of LabJack Channels in DAQFactory project + custom DLL load with secondary dependencies). My understanding is that a process can change its own environment variables (e.g. Path) and those will get passed to child threads and processes (like the DLLs when loaded), but obviously doesn't change it for complete other processes. All that said, I was able to reproduce the second problem (but not the first) with my own application using LoadLibrary and GetProcAddress, so it's certainly possible I'm just missing something about how the loading works, but all the same I still didn't have any of these issues until I added exporting or LabJack channels to my DAQFactory project. Anyway, problem is worked around for now. For others who may encounter similar problems: try delayed loading of dependent DLLs if relevant. I still have no legitimate solution for the original export problem that started this thread (I'm using my own DLL to export now).
  18. gkimsey

    Help! Strange Bug With Export + Dll File Write

    False alarm in the previous post: Using absolute paths did not fix the DLL loading problem completely, just for one of three instances. So I'm still confused.
  19. gkimsey

    Help! Strange Bug With Export + Dll File Write

    Okay, this became a big problem again, but I may have discovered a solution. Up to this point on my main project I've been developing without hardware, simulating input signals with global variables and such. Now I'm integrating hardware with a LabJack U3-HV. I am not actually using the hardware in any sequences, but by simply enumerating channels (which do work, and behave as expected), now DLLs won't load. It seems similar to the above problem where a built-in DAQFactory functionality causes DLL problems if enabled, but the problem goes away when that functionality is disabled. For kicks, I removed all the channels again and sure enough the DLLs can be loaded again. It seemed like the environment PATH that DAQFactory is using might somehow be changing based on whether the LabJack DLL was being loaded, and maybe that means DLLs in the CTL file's directory aren't in the PATH any more. Or it could be more related to the original problem that started this thread. When I changed the DLLs to absolute paths instead of relative paths in the extern() calls, they worked again. I think DAQFactory's search path is changing based on what is being loaded. To be clear, I've been opening the project by double-clicking the CTL file in order to use relative paths, which I mentioned in another thread was helpful for making the project portable and supporting multiple copies/versions of the project and all DLLs on the same system. It seems this is not a consistent method. The reason I think this ties back to the original problem is that the DAQFactory export may have done something similar to the path, causing the DLL file writes to be operating under a different working directory than they should have been. However it doesn't actually SOLVE the original problem directly because the code... extern "C" SIMPLEDLL_API int fnSimpleDLL(void) { FILE * outfile = fopen("simpledll.txt", "a"); fprintf(outfile, "Hello\n"); fclose(outfile); return 42; } [/CODE] ...uses a file name path relative to the working directory which was probably changed to some arbitrary location based on DAQFactory's ExportSets functionality. I'll work on porting everything to use absolute paths. If I'm right in my analysis, relative paths simply aren't supported in DAQFactory. It would be extremely valuable to be able to use relative paths (by not having the working directory change), or at least to *know* what the working directory was through a system function of some sort. Please let me know if you have any suggestions for portability and allowing DLLs which use relative paths to work. Thanks
  20. gkimsey

    Help! Strange Bug With Export + Dll File Write

    I hadn't realized I could use Depends on DAQFactory -- thanks for that. Looking into the CRT libraries, some more, I can't find any evidence to suggest that there would be any conflict between DAQFactory and my DLL with them, as all I'm doing is fopen, and not using the returned handle anywhere else. The wrong calling parameters initially seems more likely (since I've certainly done that before and it's produced very wonky behavior), but it's a simple no-parameters-returns-int function, and it only has a problem if I export with DAQFactory first. None of my testing of this sample DLL has had trouble outside of that exact scenario. Besides further chasing down the theoretical calling parameters problem (is returning int, compiled under Win32, a problem when interpretted as long by DAQFactory, also a 32-bit application?), I'm not sure what I can do without seeing the DAQFactory export source code, or at least being able to look at the file stream that's opened after the first export. Probably a moot point since my workaround is still doing the job, but I feel like the sample DLL and tiny CTL project don't leave much room for error on my end, especially since the behavior persists on several PCs (including a 32-bit one running Windows XP, which should definitely eliminate any 64- vs 32-bit problems)
  21. gkimsey

    Help! Strange Bug With Export + Dll File Write

    That makes sense. If DAQFactory has an old module loaded and Any recommendations on tracking down which DLL might be the cause, or ways to avoid this? Since it's very basic file access (no unusual libraries) using the default DLL project under Visual Studio, it doesn't seem like it'd be easy to fix from my end. Because DAQFactory is the master process here, I don't have a debug environment with which to see what modules DAQFactory has loaded. If I did, I could cross-reference those with the modules opened by my DLL when run from a basic test bed, and see where a conflict might be.
  22. gkimsey

    Questions about file I/O

    Going back to Brian's #1, being able to fetch the directory of the CTL file being used would be extremely valuable. I'd like my project to be fairly portable without needing to have the user select the directory that my DLLs reside in (they are packaged with the CTL). Admittedly I can save this location to the registry so it's a one-time deal, but then I can't have multiple copies of the project in different locations on the user's drive without loading DLLs from the wrong place. Edge cases, maybe, but it seems harmless to be able to get the project file's directory at runtime. I was surprised to find out on this thread that you can't do it. Side note: Since I'm running a handful of DLLs anyway, is there anything I can do in a DLL call to get this information? If not I may have to use a batch file or similar to start DAQFactory instead of the CTL, and save off the directory that way.
  23. gkimsey

    Help! Strange Bug With Export + Dll File Write

    Attached is the source and project files for SimpleDLL. Compiled for Win32 under Visual Studio 2010 (Express OK). Since posting the problem I've made a new DLL to replace DAQFactory's export in order to work around the problem. There were other benefits to this in my project (mainly being able to use ftell() to get the log file's size without having two separate file handles open). I'm still interested in finding out the problem, though, so I can start using export sets again later. SimpleDLL.zip