pharos-bts

Members
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About pharos-bts

  • Rank
    Newbie
  1. I left an application in RunTime mode overnight; at some point the screen power saver kicked in and blanked the display (probably not relevant). Next day on bringing the screen back up, the 2D graph on the displayed page was completely blank, though still there (clicking on component showed outline and properties were accessible). All other components on that and other pages were OK. Checking the component .visible flag it claimed to be visible (I don't hide it in script anyway). Short of closing and restarting DF I could not get a way to restore the graph; I tried adding a trace etc but to no avail; copy/pasting the graph to another page still did not show it as more than just the click-to-drag outline, or green/purple frozen indicator. I deleted the component and made a new one, so far it hasn't happened again. Which raises another possible issue; DF often crashes on me if I try to delete more than 1 screen component in quick succession. I have got in the habit of saving after each deletion. This is on 5.82 (and earlier versions). Just wondered if these minor gripes are known issues ? Regards,
  2. pharos-bts

    USB Virtual comms (UDIN-44)

    Your summary about the bad Virtual com driver behaviour was spot on: I reprogrammed everything using the direct .dll approach, which took a good bit more effort but now it works well. DAQFactory doesn't crash when an open device is disconnected, and by closing and re-opening the device handle I can resume data collection once it is plugged back into the USB.
  3. pharos-bts

    USB Virtual comms (UDIN-44)

    OK thanks, that makes sense. I'll have a look at their .dll documentation and see if I can approach it that way within a reasonable timescale.
  4. I'm using a UDIN-44 USB I/O controller from Audon to read/write some 24V digital signals with DAQFactory 5.81. It works fine using the virtual com port assigned when installing its driver, and a simple ASCII sequence to read or write to the I/O bits. But if the device is momentarily disconnected from the USB port, DAQFactory immediately takes up 100% CPU time and the PC locks up requiring disconnection of power. This happens even with a blank DF document containing only the serial driver Quick Device Configuration ie which virtual comms port & protocol is used (9600-1-8-N); no inputs or polling being setup. The problem doesn't occur if the device is connected after DF starts running, only when it is hot-disconnected once communication is established. By comparison the test program supplied with the device does freeze for 3 or 4 seconds after momentary disconnection with a 'failed to connect' message, but then picks up communication again and carries on. The supplied drivers refer to the 'Native USB device driver for FTDI FT8U232/245' (Future Technology Devices International). Is this a known issue, and/or do I have to live with the possible inconvenience ? Thanks for any input