Mellroth

You are welcome. I would suggest to take the ferry to Port Ellen but depart from Port Askaig, since the ferry can take you directly to Oban. Next stop, next whisky I had to look up the name of the place where we stayed, and my memory served me well, the name was Kintra http://www.kintrafarm.co.uk/ Brings back a lot of good memories: 3 days, 7 destilleries, ~20km by bike. I tried to upload a picture with a view from our stay, but failed (don't know why). Anyway, sitting in that small pub, drinking whisky and beer eating garlic toasts, Mmmm :thumbup: :beer: /J

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

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

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. /J

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

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

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

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

Good, I searched the other threads and saw that you had posted another question earlier. 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

* 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 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

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 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

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

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

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

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 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

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. 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. 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 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

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

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

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