Jump to content

ThomasGutzler

Members
  • Content Count

    191
  • Joined

  • Last visited

  • Days Won

    21

Everything posted by ThomasGutzler

  1. Ok, I obviously got fooled by the abstraction of the VISA driver. The reason why my initial code "works" is that I never enabled the Term Char. Without looking up the details of the communication protocol over USB I'm assuming that it contains some sort of "message end" that isn't a term char but is understood by VISA. Otherwise, I'd be getting timeout errors on the 65535 byte reads. Nevertheless, I have changed my reads to the suggested method (but without term char enabled) and queried the scope using the old method until I got another timeout. And there is no timeout using the new
  2. I see where you're coming form @crossrulz, but if the presence of a term char in the data was a problem, why am I getting exactly the right amount of bytes?
  3. Hi, I'm connecting to a Rigol DZ1000 Oscilloscope via USB and using the :DISP:DATA? ON,0,PNG command to grab a screenshot. Reading out the data in blocks of 65535 bytes until there is no more (see attached vi). This normally works fine but yesterday I was getting a timeout error. I fired up IO Trace and got this: > 783. viRead (USB0::0x1AB1::0x04CE::DS1ZA201305475::INSTR (0x00000001), "#9000045852‰PNG.......", 65536 (0x10000), 45864 (0xB328)) > Process ID: 0x000039C8 Thread ID: 0x00001760 > Start Time: 13:13:54.1169 Call Duration 00:00:10.4323 > Status:
  4. We use Macrium, the free version. It does the job. Also never had to restore... yet
  5. Thanks @LogMAN and @drjdpowell, I was unaware of the "Diff" vi. I'll use it to throw my own error. ☝️
  6. Help Is there a way to parse this JSON string into this cluster in the following way: - The order of elements inside the "Parameters" cluster does not matter. No error - I can use enums - The name of the elements matter. "TWOoo" shouldn't end up populating "two" (even if the order of elements matches the cluster). I want an error here instead of "two" being the default value - Don't care if JSON text has additional elements that aren't in the cluster. No error In short, features: Strict name checking, order independence, error if element missing I've tried so many
  7. I'm happy for my vim to break when a uint is wired in. Just didn't realise that's the problem. Thanks for pointing that out Francois
  8. Drop this vim on your block diagram and connect anything that isn't an I32 to the "Type" input and it'll break. Why?
  9. I can download them both. Maybe you need to have an account for the download to work. I had to create an account to be able to upload.
  10. Unfortunately, nobody seems to care about this any more Even with the newly provided example
  11. Good find! @Jim Kring happy to assist in any way I can when you're looking into this bug.
  12. I made a new .zip with the current versions of all files. Would be cool if someone else with a VIPM pro would try to build this just to check if it's my problem. Cheers bits.zip
  13. Minor update, I've gotten rid of the different type cases by doing this While that makes the code prettier, it also prevents it from building into a vipc due to the same issue: nested vims
  14. Hi, I'm having problems building a vipc from a vipb with files containing nested vims. Getting the following error from VIPM: ERROR: 7: VIPM API_vipm_api.lvlib:Parse Build Return Message_vipm_api.vi<ERR> Code:: 7 Source:: 0053C289D635723F5DC0A4F08297566A<ERR> The following source VIs or Libraries are missing. Please correct this problem before rebuilding. b39afad9-8321-4719-86a9-dddab325fc87.vi The following source VIs or Libraries are the callers of missing files BitsSetter.vim I created a zip with the vims and the vipb file. Any suggestions how to fix this? Openi
  15. Using my company's template which is basically a JKI statemachine with OpenGDS active objects sprinkled on top which communicate via queues and/or events
  16. Turns out that deleting the VIPM cache (C:\ProgramData\JKI\VIPM\cache) fixes the problem. With the cache folder gone I restarted VIPM and it created it again with fixed permissions and running happily for myself and the system user which is used for CI builds.
  17. You're right, running VIPM as admin works but I'd still like to know how to fix the problem rather than work around it.
  18. No, the account is fine. The CI build (system account) still works. The problem is when I log in manually to debug a problem. I just don't know where to look for those files it's trying to access or which files those are.
  19. Hi, Over night something changed on my windows 10 build server and I can now no longer open VIPM. It just shows the splash screen and then closes again. Here's the log file: =========== START of VIPM 2018.0.0 (build 2025) Error Message =========== An internal VIPM 2018.0.0 (build 2025) Error has occured on: Tuesday August 20, 2019 at 03:19:48 PM = Automated Message Start = Error 8 occurred at Open/Create/Replace File in NI_LVConfig.lvlib:Parse Config to Queue.vi->NI_LVConfig.lvlib:Load.vi->NI_LVConfig.lvlib:Open Config Data (compatibility).vi->DDEFA05621
  20. Or Get Volume Info if you're only interested in the "C:\" part of it
  21. Thanks for throwing ideas around. Let's debunk some of them. I don't think it's a hardware problem, because a power cycle of the DAQ wouldn't fix that reliably and a reboot of the PC wouldn't break it reliably. The DAQ is connected to an Intel NUC directly to the onboard USB port. I tried different ones with no luck. There is no funny software running that interferes with the USB ports PC is set to never sleep. Power management was enabled for USB hubs, so I turned that off and rebooted the PC. Same problem Status Code: -88705 The specified device is not present or is not ac
  22. Hi, I'm having a problem with two of my PCs that have a USB-6356 DAQ connected. Every time the PC reboots the DAQ isn't recognised in NI MAX or LabVIEW or NI Device Monitor. The DAQ reappears after I power cycle it. Any thoughts what the problem might be? PC is running windows 10 Pro and LabView 16 Cheers
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.