Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


ThomasGutzler last won the day on January 20 2020

ThomasGutzler had the most liked content!

Community Reputation


About ThomasGutzler

  • Rank
    Very Active

Profile Information

  • Gender
  • Location

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since

Recent Profile Visitors

2,671 profile views
  1. What Neil said. Looks like you've got it worked out. The hardest thing to get your head around is the factory instrument creation. This is the only place where you might not use dynamic dispatch to call instrument specific vis containing their specific configuration. But as @drjdpowell said, you can use JSON for that.
  2. Factory is a good way to create your instruments but you probably want one factory for all instruments rather than one for each type. That way you only pass the parent (abstract) reference around, which makes it easy to swap out one concrete instrument for another of the same type. Returning different data types from classes of the same instrument type is something you don't want. When designing your classes, you should already know what kind of data you expect that class structure to handle and all instruments of one type should be able to put their data into that one given format. Maybe
  3. 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
  4. 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?
  5. 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:
  6. We use Macrium, the free version. It does the job. Also never had to restore... yet
  7. Thanks @LogMAN and @drjdpowell, I was unaware of the "Diff" vi. I'll use it to throw my own error. ☝️
  8. 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
  9. 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
  10. Drop this vim on your block diagram and connect anything that isn't an I32 to the "Type" input and it'll break. Why?
  11. 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.
  12. Unfortunately, nobody seems to care about this any more Even with the newly provided example
  13. Good find! @Jim Kring happy to assist in any way I can when you're looking into this bug.
  • Create New...

Important Information

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