ShaunR

If I have any question, may I ask you again?

That's what we're here for

What is it? What does it do and what is it for?

Thanks for your input. If I had the CVI tool available I'd be glad to rewrite all my VISA drivers. I'd get paid to brush up on my amateur C skills and I wouldn't have to worry about the manufacturers' questionable driver quality. Sadly I don't have that, or the time. The OOP solution sounds interesting, if convoluted....learning how to use that would be useful in general. In the mean time I guess I'll just scrape by with non-generalized code.

Sorry if this issue has been discussed thoroughly somewhere else....why is that a bad idea? I've implmeneted semaphores in most of my drivers so there's no potential for collisions (I'd use VISA lock/unlock but can't seem to find a similar version for IVI...).

Well. You've already run into one on the major problems (race conditions) otherwise you wouldn't have had to use semaphores. You wouldn't need to do that if you'd used (say) a functional global.

Another issue is that global variables significantly complicate debugging especially for people not as familiar with the code as you are. You, as the developer, know every inch of your code and can probably tell by the symptoms where bug is probably hiding. I, as someone not as familiar, just see a sea of globals in many sub VIs (could be hundreds). Where do I put my probes? I cannot probe the global itself (Unlike a functional global).

The original argument for globals being bad practice was that they break the data-flow paradigm of labVew. Now that LabVvew is being promoted as an OOP language, this is a bit moot. But it isn't just labvVew where it is perceived as bad practice. Most languages suggest that local variable scope is the preferable solution. However. I can think of 1 or 2 situations where I would go against the flow and use a global variable.

I'm sure others will chime in with their thoughts, but I would guess they are not supportive of global variables.

Hi all,

I'm new to lab view as well as this forum. I'm having trouble figuring out what I need to interface labview with either an off the shelf linear stage or a DC motor.

From what I understand, there are primarily 3 options for DC motors:

1. DC motor with an encoder bought from a place like maxon

2. DC Stepper motor with an encoder

3. DC Servo

I realize that there's a fine line between DC motor with encoder and DC servo as in the case of the servo, closed loop pid control is done on the servo its self.

What is needed to interface the motor or linear stage to lab view? Does lab view use RS-232 to communicate to the motor drivers? Do I need to purchase a motor driver from lab view? What would I need to interface this 450mm Linear Slide to labview? Once it is interfaced, I want to use labview to control the rotation of motor inherently controlling the position of the linear slide

Thanks

Labview can easily write to serial devices. You don't need anything other than Labview itself.

The product you are interested in also has Labview drivers (and examples) which are downloadable here from the manufacturer.

Huwaaaaahhhhh ShaunR,

It's work perfectly !

I was tried to close the Vis, open it again, run it, close it, open it again, run it (ehehehe) several times and no error.

Thank you so much ! Thank you for assisting me this far, Ehehehe...

Is there any appreciation in this forum like NI forum (mark as a solution) ?

Sweet.

Press the green plus "+" on the right of my post.

As you are using TCPIP to transmit your data.

You might want to take a look at dispatcher.

No, it's not functionally identical. Your version will shut off the output as soon as the process variable is in the range of the setpoint +/- the deadband. Mine keeps the output on until the process variable is greater than the setpoint + deadband, then turns the output off until the output is below the setpoint - deadband (a form of hysteresis).

No (or is it yes?). You are correct. It's not functionally identical. But the OP was struggling with some very basic concepts and I didn't want to cloud the issue when his next step was to remove it anyway (he never got that far ). I also wanted to give some credit where credit was due.

Any control algorithm for this situation will necessarily vary the amount of time that the output is on.

Indeed. But an on/off controler doesn't do that in response to how near or far away from the setpoint we are. Its a bit like having On/Off brakes in your car. It doesn't make for a very smooth journey.

What I was trying to say is that PWM doesn't make much sense when the PWM and PID run at the same rate. Let's take your example with 1 minute periods and the PID calculates the number of seconds the output should be on. Say the loop runs once per second and it calculates that the output should be on for 30s. Now what? Do you turn on the output for 30s, turn it off for 30s, then run the PID again? That's going to slow your control response substantially. Or, you run the PID again one second later and it calculates the output should only be on for 10s. How long should the output be on? If the PID output is 0s on the iteration after that, do you turn off the output immediately? If not, then your control probably isn't going to be great. If so, then you should be using a simpler control algorithm that provides a boolean output instead of the analog signal provided by PID, as I was trying to explain.

An averaging PWM output (where we are trying to simulate a voltage level) typically runs at about 20-40 KHz. The lower the frequency the "choppier" the output. Why 20-40KHz? Because that is higher than the frequency response of most analogue inputs to give a stable reading (read DVMs which is about 20Hz-20 Khz) . And that is due to the input filtering of the analogue device . But we didn''t have the hardware to do that and we cannot run our loop fast enough (or accurately enough) to do it in software (without a real-time OS). But do we really need to? Well. for long lag systems no. A long lag system may have a frequency response anywhere between 0.1 or and 0.0001 HZ. That we can achieve in software. We can run our PWM at very low frequencies. And it works very well.

So the answer to your "then what?" is A. "you turn on the output for 30s, turn it off for 30s, then run the PID again". In the example you will only get reasonable control if the response of the system is more than 10 mins (preferably more). But it will be far superior to the an on/off controller.

Now the interesting part is that when you characterise a system to find the PID parameters. Because it is a closed loops system, Your control method becomes part of the system (regardless if its digital or analogue). So the PID algorithm is not only trying to predict the behaviour of the target system, but the target system AND the control. This is why I was taking you to task on your statement that PID is for analogue devices. It isn't. It's a predictive algorithm. Nothing more. We could use (and I have used) a bi-section algorithm just as easily.

Always nice to hear that others think the same

Indeed. It confirms my suspicion that I'm really not as stupid as I look

For clarity I prefer to use the cast, and because of constant folding I believe that there will be no hit in performance.

Can't argue with that. Readability over elegance (no performance hit). But in contrast to your previous statement. computers definitely don't think like me.

Hi ShaunR,

The VIs diagrams thatt you post yesterday, it works but the image display is non-current like stammering.But no error at all...

Yes. That is because it is in fact a single reference (something I always hated about the vision stuff but I guess a necessary evil).

So we really need to use something that makes a copy of the image and transmits that rather than the reference

But we cannot use the conversion to an array because you cannot open it (is that right?)

Try changing the standard flatten to string to the IMAQ one.

If it is all about performance, how about this;

/J

Yup. that's my solution too. Except I just used the value d92 instead of a cast

I think IE is the only one to work directly?

Do people still use that?

OK. so really we are just talking performance here.

So with this as the seed. What's the execution time?

Drag the image to your block diagram, (if using 2010).

2009. I just get a hyperlink. But I'm beyond caring now .

you can import the snippet into LabVIEW and run it.

And how do I do that?.

Wheel invented:

Let me know if you can improve on this.

upload it then

Hi, I'm new to the board, sorry if this is in the wrong section or anything. I did search for this topic and found nothing. My problem is this:

I have an automated tester using 5-10 different instruments. Some of the equipment isn't always available so I want to enable my software to use one of several models (with different drivers) for the same role in the test. The problem is that some units use IVI drivers, while others have VISA-based drivers. IVI sessions can't type-cast into VISA sessions, or vice versa. I could use plain text to pass the instrument addresses around, but wouldn't I be losing other data stored in the session?

I normally store my instrument sessions in a global to simplify the wiring to all my sub-VIs (is this bad practice?). My current solution is to use one VISA session, one IVI session and an enum which lets the sub-VIs know which one to use. But it would be much nicer if I could somehow create a "wrapper" session that allows me to treat the IVI device as a VISA instrument. Is that possible?

Hopefully I'm not doing everything horribly wrong...I'm completely self-taught and have spent a long time trying to come up with "good practices" without much external input. Thoughts?

Well.The intention of IVI was to do exactly what you are describing transparently, but you've found the weakness in the plan Its a good idea (note I say idea because I'm all for interchangeable drivers) as long as your all manufacturers do it (which they don't). But the real killer is you can only create them in CVI (that I'm aware of).

So the "proper answer" is to take your current drivers and turn them into IVI drivers. But that's no good to real people.

I would take a look at Transport.lvlib (you will need to unlock the library to see the guts). It won't help directly, but it will show how I resolved the same problem for for TCPIP, UDP, Bluetooth refs. You will be able to use the same technique to transparently switch between the two systems..(But the age old addage applies....."If it ain't broke, don't fix it!" )

I normally store my instrument sessions in a global to simplify the wiring to all my sub-VIs (is this bad practice?)

Yes.]

I use LV 2009 under Win7.

Thanks I'll look into it.

I noticed I didn't address your other observation. I expect you read the note in the diagram of the FG. I too am not happy with it (apart from just being a mess ).

Mainly because It currently is not only used for storage, but also to relay disconnects and close connections. This needs to change so as to separate the roles (its a legacy from a previous incarnation).

I have to come back to it for the addition of other features and I'm still deciding on the best approach at the moment.

I agree to you.

A little issue I found. If I let the IP-Adress blank, I get errors on openning connections. So I have to write "localhost" to be connected.

May be it would be better for the example application to set "localhost" as default value?

Interesting.

What version of LV and OS are you using?

.It was tested on 3 machines using LV 32 & 64 on win7 and vista (I don't have XP or a linux licence). And everything seemed fine.

But as it HAS happened, I'll include your suggestion with the next release. Thanks for persevering

Let me guess: Basic Object Flags?

Did you get any "insane objects" when closing the VI before you stumbled on the right bits?

And our rep-point winner is!

Nope. None. And I tried all bits on (almost) every object

Ok, now I understand it. So you have a sender task for each publisher (service) on the dispatcher side. Why not one for all? My dispatcher does all, registration, unregistration an sending in one loop, but each service has own receiver loop. I think this is the biggest difference between our realisations of this pattern. The second less difference is you use functional global variable for the client list, but I don't.

For all, I think it's very interesting pattern, which can be used for dynamic applications, where many publishers and subscribers can communicate to each other.

Thank you

Mainly load balancing and performance. The performance is dictated by the computers resources rather than the dispatcher. With the filtered method you have a congestion point that affects ALL "Topics" and gets worse by a factor of subscribers x topics as you add more topics.

Lets say (for example) you are sending 100MB of data on 1 topic which takes (say 10 ms) to transmit to 1 subscriber (we'll ignore filtering overhead). The Dispatcher is able to service all subscribers to that topic every 10ms. If we now add a subscriber to that topic. The time to service all subscribers is now 20 ms. 3 subscribers...30 and so-on. Now we add another topic that also takes 10ms to tx 100MB of data to 3 more subscribers (keep the maths easy). The time now required to service all 6 subscribers on both topics is now 60 ms. 3 Topics, 90ms.......

However. with the service handler, each service handler is only handling 3 subscribers so in our theoretical example, each handler is servicing all 3 of the subscribers every 30 ms still. Increasing the number of topics doesn't change the time to service all clients. So whereas before the time to service all subscribers was a compound of the number of subscribers AND topics. Now it is only the number of subscribers.

Additionally, whilst the dispatcher is servicing the clients, it is effectively "deaf" to incoming connections which also gets worse as you increase topics and subscribers. Having the dispatcher only handle connections means that this "deaf" time is not dependent on the number of subs/pubs. You can use a queue as, I have, and build a list of connection request but you then have to consider the trade off between handling data or handling a connection request. With significant network lag you can get halts in the data whilst the dispatcher is creating a connection. In my example, the Dispatcher only handles connections (its very responsive to connection requests). Therefore the dispatcher can take as long as is necessary without interrupting the data streams.

I was able to get the original file zip that you posted yesterday. I able to open it again, run it, it works then I close it, try to open again and the error comes out.

And then I try to create my own programs based on your VIs diagrams, it works but when I open, the error comes out again.

But let me try your VIs diagram that you just post, I think there is something different from your previous VIs. I will let you know if any progress.

By the way, thank you for assisting me here.

Yes you are right. Apart from adding the "Dispose" I also removed the conversion from an image to an array (and visa versa) as I indicated in my previous post. Although I don't think it will solve your problem (but we can hope )

Yes, it was lost after updating LAVAs software (I think). Here you can download my version:

http://labviewportal...hp?f=19&t=9#p19

Sweet. I'll take a look!

But, sorry, I don't see where you send your data from one publisher to many subscribers. TCP/IP is one to one connection, so you have to send your data twice if you have two subscribers. I can't see any for-loop in TCIP Write.vi.

Indeed. That's where the "Disp Service Handler.vi" comes in.

This dispatcher uses a similar method to a web server where each incoming connection is negotiated to a different port and a process is spawned to handle that client. However. This spawning only happens for the Publishers. If you look in the Registration part of the Dispatcher you will see I dynamically launch the service handler (whos front panel is hidden). The publisher writes to the service handler, not the clients and the handler deals out the data to the clients. There is a service handler for each publisher and when a subscriber wishes to connect, the Dispatcher sends a new subscriber list to the handler for that service.

Very cool indeed. Usually things like this can be found out by using the highlight execution but this one does nothing.

You can however find the wires by when the mouse changes to a pointer. (to the left of the wait function is one) Odd that it hides the wires but still allows you to select them by clicking them, but not by going to Edit >> Select All.

Indeed. Also If you cut and then paste back again, it will reveal the terminals. 'twas just an idle moment whilst rummaging around the script stuff. But in doing so I did find also that using this "feature" I could remove the thick border around terminals and variables which was one of requests from the idea exchange.

Is it because I'm using version 8.5?

I read from NI forum tells the errors comes from 8.5 bugs, so I need to move on version 9.0 SP1. Is that correct? I haven't try yet, so any other opinion?

It's difficult to say why. But as NI have reported this as a bug in 8.5 for loading vi's saved to a previous version then its likely to be the case.

As you were able to load it the first time.I would suggest you over-write the vi from the zip. Then reboot to make sure memory is clean, and open the VIs again.

You should now be in the same position as when you downloaded the file originally (hopefully).

If you are able to load the VI again, save it to a different location so that it is not a "converted" vi. Hopefully by doing this whatever the issue is with loading converted VIs will be removed.

I have also posted the VIs diagrams below (they aren't difficult). It would only take a few minutes to re-write them.

x86 for me:

Running 32-bit LV2009.SP1 at the moment.

x86 32-bit or 64-bit?

I have both installed under win7 64-bit. It takes about 15seconds just to launch 32-bit LV. About 5 seconds to launch 64-bit LV. Disk IO is particularly sluggish using WOW 64

[LV2009]

Whenever I open an installer build spec, that is for a med + size app, I have to wait ages for the dialog to appear, then wait a bit more for it to become editable.

(Way more than for a executable build spec, and sometimes that takes a bit)

Sometimes I find its easier to edit the XML directly then to wait, (off the top of my head, I can't remember 86 being as bad)

Its like its doing a bunch of checks, but nothing really changes between opening it from the last time.

I am talking minutes... ...anyone know why?

Cheers

-JG

You running LV x32 on a Win x64?