Mellroth

If it's the same peat then I'm up for it - it's that it's strong but also complex that wins me over - how much does a bottle of Caol Ila go for?

It costs less than Lagavulin, I found this online shop that sells Caol Ila at 44$ a bottle

http://www1.shopping.com/xFS?KW=caol+ila&x=0&y=0

If you ever go to Scotland, you must visit Islay. Me and my wife bicykled all over Scotland 10 years ago, and we both liked Islay a lot.

Whether it's due to the good whisky I don't know, but we had a really pleasant stay at a small Guest house close to Port Ellen. Kintra was the name I belive.

/J

...Can anyone tell me why this could be?

What happens in the other event cases? Especially the timeout case?

/J

...big fans of sigle malts from the island of Islay, particularly Lagavulin, Laphroig, and Ardberg. These three distilleries happen to sit right next to each other on the island...

This just make me love LAVA even more, discussing scotch during working hours :thumbup:

Ardbeg is currently one of my favourites, and another great whisky from Islay is the Caol Ila (it is supposed to use the same peat as Lagavulin).

Otherwise I hope you have tried the double matured versions of Lagavulin and Talisker.

Time, say the islanders, takes out the fire but leaves in the warmth.

/J

...It is equivalent in function to the 'randperm' command in MATLAB...

I think that the randperm function in MATLAB generates numbers between 1 and N.

Maybe add an option to select if the sequence is zero indexed or not?

/J

ARRRRRRGHHHHHHHHHHHHHH.....

i had a long talk to the techs about modifying these files etc.... and explained to them that it messes things up when these files are played around with , and , guess what , you got it , they still messed around with them... rather than go through all the hassles of changing everything over to hidden and encrypted files i have decided to play games with the techs and put the burden back on them...

I think you can solve this issue by creating a LV exe that is run as a NT-service.

The only thing this exe would do is to open the file/files and keep them opened.

This will prevent any user from editing or deleting your files, but they can still be read.

/J

...NO,i can't read replies,but it is show that the device is ok! and i can open the visa test panel.

If you cannot communicate with the instrument through the VISA test panel, you should really check your communication settings.

When the test panel fails, it will most likely fail in LabVIEW as well.

/J

That's a big problem, because we whanted to make the plugins replaceable while the main program is running, which of course can not be done if these vis do not unload.

BTW it's not important if i work with the class, the simple call of Open VI Ref let stay the vi in memory even if it was closed again imediatly afterwards

How do you open your references, can you upload an image or some code to show us?

/J

...my instrument is advantest spectrum analyzer U3700 series U3751

Good, I searched the other threads and saw that you had posted another question earlier.

...the instrument supports GPIB/LAN interface.

now i want to control the U3751 through LAN interface.

in the MAX,i have configed it,it's ok.there are no problem.

When you say that it is OK in MAX, do you mean that you can send commands and read replies in MAX?

In the other thread you were sending "*IDN?\n", if this works, then I think you should try to add \n to your LabVIEW code as well.

This relates to the communication settings I mentioned in a previous post.

If you need to change your VISA settings, you can do this by wiring the VISA refnum to a property node.

The property node will give you a number of options to configure the VISA session, e.g. the termination character.

/J

...but there is the same error,it look like that the instrument is not controled.

what can i do ?...

* Can you PING the instrument from the CMD prompt?

* Check instrument communication settings.

* Check how a message transfer is ended, e.g. by CR/LF.

* Use a network sniffer, e.g. Ethereal, to check if there is a network problem.

I can not offer any more help unless you post information regarding the intrument, e.g. I don't know whether you are using a SCPI compliant instrument, and I don't know the command set of the instrument.

/J

This goes for U8,U16,U32,U64

It shows no coercion dots, this issue will be quite hard to deal with...

This is the same as if you just skipped the conversion node, except that you would see a coercion dot on the U8 terminal, eventhough the value is typecasted.

Actually, this is a good example of when you could run into trouble if you perform any actions on the coerced U8 value. If you see a coercion dot on the U8 terminal, you have to deal with the I8 number so that you get the conversion that you want. In this case, you should add a range check to remove negative numbers.

/J

Error -1073807339 occurred at an unidentified location

Possible reason(s):

VISA: (Hex 0xBFFF0015) Timeout expired before operation completed.

You can use probes to find out which node is actually generating the error.

Most probably it is the VISA-Read that generates this error. If it is, I think you should check your manual to see if a *RST really generates a response. You could also try to send another message right after the *RST, e.g you could try "*IDN?".

As I don't know which instrument we are dealing with, there is not much more I can say.

/J

PS. Get rid of the first "Simple Error Handler" node, this adds nothing to your program.

...I don't agree, this issue (coercion dots) are more something for the advanced users...

I haven't teached LabVIEW for some time now, but if I remember correcty, coercion dots is introduced in BasicsI (or II). If it still is something that NI teach new LabVIEW programmers they should avoid, there should also be a tool that helps you find them.

/J

I just want to pass values from one function to another with out having the clutter of wires everywhere.

Beware, LabVIEW is all about wires... :laugh:

Seriously, I think you should think twice before removing all your wires in favour of Locals. With Locals you have less control of the flow, and you can run into race conditions.

You might want to have a look at one of the GOOP implementations, these can replace all your data by a reference to that data (basically you get a by-reference approach).

/J

yes, but shouldn't that feature allready exist in the BASE Package, due it's importance? What do others think about that?

I agree, it could be next to the "Show buffer allocations.." tool.

/J

Is Labview Real-time a different software?

I would say that it is a different platform and a different software. LabVIEW RT module is a LabVIEW add-on that runs on a Real Time OS called Pharlap.

You can install this RealTime OS on a standard desktop PC, but you have to check your ethernet chipset so that it is supported.

http://zone.ni.com/devzone/cda/tut/p/id/4480

Once the RT OS is installed, you will have access to microsecond resolution in timed loops etc. (you might have to change an ini-file key for this to be enabled on a desktop PC).

You can still try the counter/timer solution under Windows, but it depends on how much jitter you can tolerate.

/J

...there could be a right-click-menu option that would change the behaviour of the node...

I rather have an additional input, because this is easier to spot on the block diagram.

Regarding the question of the default behaviour; I'm usually not that found of changing a default behaviour since old time users wont read the help, but use the node directly (I really hate how NI changed the default behaviour on some of the file VIs, e.g. convert EOL is now default).

But, in this case I can agree that it seems like the way to go since we are speaking of something that is "very" close to a bug.

I also did a quick check on some of my old projects, and I can not see that any of these should have any problem with this new behaviour.

/J

I need it to blink at about 10Khz.. and until now I managed to work at most at 1Khz, as stated in my previous message.

So I guess that a VI that I will need is one that gives one of the data pins of the parallel port the value "1" for 0.1 ms and then "0" for 0.1 ms and so on.

I think you will find it hard to get that performance (10kHz), assuming you are using windows, depending on your pulse requirements. With windows you never really know what is going on in the background.

What you could do is to install a DAQ board, e.g. http://sine.ni.com/nips/cds/view/p/lang/en/nid/202004.

Then you can use the onboard counters to generate the desired pulses, specifying the frequency directly.

If, however, you still like to use the parallel port, a DAQ board can be used as Timing source for the TimedLoop structures, enabling you to get better resolution in the loops.

Good luck!

/J

This isn't so much a reentrant/non-reentrant issue. It's how does a single node that gets different refnums at different times behave.

What I'm trying to say is that when you put a W4N node in a non-reentrant VI, all instances of that non-reentrant VI could hang due to that notifiers a fired in the wrong order/too close in time. So we would have a system that look exactly the same on the Block Diagram, but behaves completely different (depending on the reentrancy setting in the encapsulation VI).

This gets extremely difficult to debug, since the conflicting VI can be used in many places and deeply nested.

I'd rather try to add a new node or a terminal for specifying behavior on the current node.

Agreed, I was just arguing that the main change would be that code that hangs in the current implementation should no longer do so. I do think that the change would have minor impact on current usage, but better safe than sorry...

A new terminal would be fine, just don't add it as a right-click-to-configure feature.

Considering that they are exactly the same code, I'd be surprised that there's any speed differences.

Its been a while since I benchmarked them, and you are absolutely right :worship: . Notifiers are as fast as queues. I did notice that if I set timeout to 0 and there is no data available, this takes longer than when data are available. This applies to both queues and notifiers.

I really do say this is not a bug. The notifiers were not designed to work in this case, in fact, they were explicitly designed against this case for performance reasons -- the bookkeeping of which message was seen last for each individual refnum is a hit that the vast majority of apps don't worry about. In the 5 versions of LV released so far with the notifier prims (not to mention several prior versions with the VIs-around-CIN-node), this is the first time that anyone has complained (to my knowledge) about the lack of support for this case. As for the question of whether or not the Wait for Notification behavior should change, I'd have to say "no" if for no other reason than we'd be breaking behavior going back multiple versions of LV.

I think that the reason you haven't seen that many complaints is that it is hard to find out what happend.

Jimi's first post used a W4N node in a loop (should have been a single W4MN node instead, I know...), but it brought the issue to the surface. As for the explanation, you (and you are the "Perfect Queue" ) had to dig deep down, to really understand what was happening, no other Power user could come up with an explanation.

Maybe we could do a poll, and ask LabVIEW developers how they think a W4N node placed in a non-reentrant VI works, when called in two different places? I think the answer is obvious, since we specify a notifier by a reference, we also expect the two W4N calls to be separated. Changing the behaviour to a situation where references are being separated, shuldn't have any impact on older projects. At the most, programs would be using the correct timeout values, and get the expected behaviour, right?

Regarding the performance, I feel that the notifiers are behind the queue operations, e.g. using preview queue element instead of a W4N node (timeout = 0) is much faster. So maybe a speed bump is needed anyway?

Just my 2c

/J

Hi,

I'm not completely sure that I understand what you want to do, but if you intend to count the number of low-to-high transitions then have a look at the attached VI. If you want to count all changes, i.e. even high-to-low transitions, just use a XOR node (boolean palette) instead.

/J

Download File:post-5958-1161009776.vi

I am new at this world

and i want you to push me

if you can help please help because i tried

thx

I know. After reading the manual, it is quite clear. A reentrant sub VI called by a CBR-node will allways execute in serial order for the same reference.

Good old Allen, " When all else fails, read the directions..."

/J

I checked this. You also have to set the modify_FGA.vi to reentrant and it will take 100 ms (i forgot that earlier). You do this, and the VIs will operate in parallel.

I still don't think that the methods can be called in parallel.

I took your original code and removed all class specific code, and then added a 100ms delay to the core VI itself.

Then I created a test VI that does the following

1. init (basically only loads a reference to the core VI)

2. get and set in parallell (just calls the core that is empty, except for the 100ms wait)

3. delete

Download File:post-5958-1160737603.zip

when I run this test the total time for get/set is still 200ms, so I do not understand how they could be called simultaneously?

/J

Aristos,

can you please comment the post from Jimi. The post where two parallell pieces of code hang, due to this notifer behaviour.

Do you really argue that this is not a bug?

If you do, wouldn't that be like saying that W4N nodes should not be put in non-reentrant VIs?

/J

Yes, the pointer version will do this (also with the external locking since it is not reentrant), but the LCOD version will not do this since this is reentrant, i think.

I don't think that the reentrant VI really offers this.

I tested to add a 100ms delay in the core__FGA.vi, then I called set and get in parallell.

The resulting time was 200ms, so even if the core is reentrant we have a sequential access.

/J

I guess it is a VISA error, just open Help->Explain error... and paste your code into the error code field.

Error -1073807343 occurred at an unidentified location

Possible reason(s):

VISA: (Hex 0xBFFF0011) Insufficient location information or the device or resource is not present in the system.

Seems like you are using a bad address?

/J