Teledyne LeCroy, but where should this be?

[*3d0g]

My apologies for leaving out the best part:

See the upper left corner.

Now granted the page where the above was lifted is dated 2019, but that's less than a decade ago, right?

[*3d0g]

Surely this MAUI Browser idea rings a bell for at least one person in this forum, right?  With all the experience represented here, someone knows how to deal with this thing, certainly.

[*3d0g]

Here's some more:

That's dated last month!

And there's finally (for this post)

Surely someone here knows how to use this with Visual Studio in some way.  This is a 2023 document.  Maybe it's just the case that everyone here uses anything but this line of oscilloscopes.  Maybe that's it.

[*3d0g]

The objective is for the scope to do everything that's needed but yet have LabVIEW running the system.  I think this can be done.

[rolfk]

Teledyne/LeCroy isn’t exactly mainstream, never has been. I never used a Teledgne device ever and a LeCroy device once. Back in those days LeCroy was known to be rather expensive, well engineered and sometimes a bit badly implemented. Firmware bugs could be very weird. Technical support was however really existing and quite helpful.

And I would never have used something like MAUI. That may look cool to the casual engineer using these devices on his/her benchtop but is nearly useless to integrate in a industrial automation system. And the idea that the driver is state synchronized with the device is a nightmare to happen. I’ve been developing some IVI drivers in the past which also are supposed to maintain state synchronization with the device. A major pitta to implement and only useful for the user if it is implemented 100% perfect!

[*3d0g]

That's what I'm seeing in all I've been reading.  It's great for the engineering bench but not good for the automation environment -- I don't want user's pushing the screen continually, and in fact I want none, for instance.  My present vision is storage of code (VB Script execution is in there, with Win10) in the scope that can be called upon to run as needed and USBTMC interface with LabVIEW, but I don't see just how to do it, yet.  It seems reasonable, that it should be possible, but I'm not yet seeing how Teledyne LeCroy's design can handle it.   

[Jay14159265]

---

@*3d0g wrote:

That's what I'm seeing in all I've been reading.  It's great for the engineering bench but not good for the automation environment -- I don't want user's pushing the screen continually, and in fact I want none, for instance.  My present vision is storage of code (VB Script execution is in there, with Win10) in the scope that can be called upon to run as needed and USBTMC interface with LabVIEW, but I don't see just how to do it, yet.  It seems reasonable, that it should be possible, but I'm not yet seeing how Teledyne LeCroy's design can handle it.   

---

I used the previous generation of Lecroy scopes with Xtream browser (the predecessor of MAUI). The issue is that all the COM code runs locally on the scope. You had to write the code (which was VB script) in a way that your system controller communicates with the scope (I used TCP/IP) and interacts with the COM programs that are running locally on the scope. You might have to do something like that for the MAUI browser. At that point you are writing LabVIEW (or whatever you like) to interact with VBscript over TCP/IP so you don't need to have a Lecroy driver other than the one that is used in the VB script on the local scope (which I would guess is the MAUI browser, and that will be pre-installed on the scope).

[*3d0g]

I'm going to make a mess of this I'm sure, but it's looking like, now (the doc's date is current, but...), there would be a default VBScript (a .lss file that is effectively a .vbs script) behind each button available on the scope, and the idea is those default scripts can be modified, saved, and restored to accomplish as is needed and possible with the scope using the OEM-installed MAUI Browser's identified objects.  The MAUI Browser is as I said earlier, like a living list, a hierarchy that all stems from the root application object always named LeCroy.XStreamDSO, and so as I can tell that has been the case for a long time, originating with the XStream Browser you referenced.  Hence, there'd have to be some means for those scripts to be called upon that didn't require a user to select buttons for the accomplishment of automation.  But I've not determined it, yet.

One thing I have discerned is it (the LeCroy system) doesn't work like it used to work, which was easier.  LeCroy frowns upon the use of a DCOM connection, now (webinars,) but yet seems to say in the manuals I must use that one is required for remote automation, and the operator must be an administrator.  Is there some way to connect with those VBScripts via LabVIEW and USBTMC?  I'm not finding an answer, not yet.  It seems very much to me that they're meaning to do it this way or do it that way, and there is no consideration for doing both. But does that mean that it isn't possible, now, when it was before?  I don't know.  I do know that this forum is a great place to try to find the answer, to spawn new thoughts. 😉 rolfk said I tend to skirt the edges (paraphrased.) Well yes, I do.  I don't know enough to know that idea can't be done, and then the crazy thing ends up working, and again paraphrasing rolfk, it ends up working somehow.    

[*3d0g]

---

@Jay14159265 wrote:

---

@*3d0g wrote:

That's what I'm seeing in all I've been reading.  It's great for the engineering bench but not good for the automation environment -- I don't want user's pushing the screen continually, and in fact I want none, for instance.  My present vision is storage of code (VB Script execution is in there, with Win10) in the scope that can be called upon to run as needed and USBTMC interface with LabVIEW, but I don't see just how to do it, yet.  It seems reasonable, that it should be possible, but I'm not yet seeing how Teledyne LeCroy's design can handle it.   

---

I used the previous generation of Lecroy scopes with Xtream browser (the predecessor of MAUI). The issue is that all the COM code runs locally on the scope. You had to write the code (which was VB script) in a way that your system controller communicates with the scope (I used TCP/IP) and interacts with the COM programs that are running locally on the scope. You might have to do something like that for the MAUI browser. At that point you are writing LabVIEW (or whatever you like) to interact with VBscript over TCP/IP so you don't need to have a Lecroy driver other than the one that is used in the VB script on the local scope (which I would guess is the MAUI browser, and that will be pre-installed on the scope).

---

Right, and I'm curious there, too.  Maybe I should dump the USB, the usual, and go for a TCP/IP path.  I'm not trying to pass huge chunks of data back and forth that'll have to be sent as googles of packets.  I'm trying to poke the VBScripts in the oscilloscope when I want to poke them.  Once I can get to those MAUI Browser objects on demand (the poke)...   Right? But then we're back to this DCOM (Distributed Component Object Model) thing.  And as I can tell, DCOM is going away (all I do is read) in the future.  It had some sort of security issue and Microsoft has been patching it in steps, for now, but is discarding it, later.  It doesn't seem like it'd be good to use it for future designs, despite my 1000 foot perspective, here.

That said, many thanks for chiming in on my thread!  There's knowledge out there, and you are the proof.

[*3d0g]

That DCOM going away part, does anyone here have anything on that?  I'm actually questioning it. ...rather it'll be mandatory updated out of use by Microsoft.