Jump to content

AlexH

Members
  • Posts

    15
  • Joined

  • Last visited

  • Days Won

    1

AlexH last won the day on November 7

AlexH had the most liked content!

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since
    2003

AlexH's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. It's true I first used it as part of an educational site license, where we had access to almost all add-on modules, but for my next job where we had to buy a single license, I was persuaded to go for that extra module on top (we have an educational discount, so it is a lot cheaper than the list price). As for the problem of having lots of individual cases for specific operations, the way I dealt with that, is to create an enum type def for each operation of a certain type (e.g. read a particular measurement quantity). One of the inputs to the statechart is an array of those enums, and in the innards of the statechart one of the subvis cycles through that array, and has a case structure for each possible measurement type. You can add new actions relatively easily by editing the typedef and adding new cases. I'm sure there are other ways to do it (some sort of actions scheduling queue for example). Usually you can categorise your actions into a relatively few types (measurement, control etc.) which means the statechart itself doesn't have to be too complicated. As for the downsides, statecharts can be a bit slow to edit (it takes a second or two to open state configuration windows), and compiling is fairly slow. They also make things a bit less transparent (I am not sure you can search for vi's within the statechart, and you inevitably add another layer or two of abstraction). The space within the state configuration dialogs sometime be a bit restrictive, so eventually you have to put everything in subvis. Also it seems to crash more often using the statechart than regular labview sessions. I think its a shame that this is a separate module, since it doesn't give you any more capabilities, just makes life easier, but it is hard to justify the cost unless you have already used it. p.s. bonus points for anyone guessing what I'm up to in the attached figure above.
  2. I've been using the Statechart module for a while now, and find it really useful. I haven't yet seen any discussion of how best to put statecharts into practice (please share a link if there is one). Some things to discuss: Synchronous or asynchronous? How do you call the statechart? What architecture to use? Passing data in and out of the statechart: Do you stick to the input/output wires, or use other methods like queues, or vi server? As for me, I have built a couple of really big data acquisition and control systems using synchronous statecharts only. I have a three loop top level VI which deals almost entirely with the user interface. The first is an event loop which deals with button pressing etc., and passes the input cluster to a queue which is read by the second loop. This calls the statechart VI every 100ms or so. It dequeues the input cluster, runs the statechart, and passes the outputs to a third loop using queues. The third loop updates the display. All of the actual action (DAQ, logging etc.) takes place inside the statechart. As well as using the inputs, I also am using queues to send commands into the statechart (for example to trigger a transition; the queue ensures the command is only carried out once.) Its possible this could be accomplished by using the inbuilt statechart triggers, but I have not tried that yet. I have found a few difficulties to do with synchronisation of what is going in inside and outside the statechart vi, but in general the Statechart module is incredibly handy. For interest here is an example of the statechart I am currently working on. (N.b. I'll be using LuaView as well to implement scripting! The lua commands will send a user event to the vi which calls the statechart.). One benefit of the statechart is that it allows you to do tasks in parallel, while communicating over (for example) a single serial port, while not worrying about communication clashes, as each state is executed in sequence. I'd be very interested to hear about other people's experiences. Alex
  3. Thanks for the replies everyone. It seems to me that slapping on a BSD license is the best thing to do, having read up on it a little.
  4. I don't think they are really in a professional enough state for the instrument driver network, but the company has said they will post them on their own website for download. I'd just like to make sure than any restrictions on their use (or lack thereof) are decided by me rather than them.
  5. Hello, Recently I contacted a company which makes an instrument that we use, to ask whether any labview drivers were available. Unfortunately they weren't and I had to develop my own, which was rather tricky but I more or less managed to do it. Now the company would like me to give them a copy of my VIs, so that they can share them on their website. I am happy to do this, even though they are not really a complete set of driver VIs in the proper labview style, but it did take quite a lot of effort, and if someone else can benefit from this all the better. Should I worry about any sort of licensing, GPL-style? I am not interested in making money, this would be so that others would be free to improve on the work that I have done without restrictions. I know OpenG VIs have some declaration on them, but I am not entirely sure about the implications of making such a statement or not. Cheers, Alex
  6. AlexH

    Skynet v 0.1

    If you let it use scripting VIs then it could become self-replicating! That would certainly provoke a not entirely welcome competition for resources!
  7. AlexH

    Skynet v 0.1

    Me too. What is particularly interesting about using Labview is that it would be very easy for the program to acquire senses! (Well maybe not smell just yet, though if anyone has a mass spectrometer driver lying around its not out of the question). Alex
  8. AlexH

    Skynet v 0.1

    I think that was more of a case of intelligent design...
  9. AlexH

    Skynet v 0.1

    It might be reasonably easy to start with an existing VI and simply try to optimise the speed of execution for example. I've a feeling that would end up with highly parallel layouts that are hard to come up with by yourself.
  10. Hi everyone, thanks for providing such a great resource in LAVA, I am very glad to see it back again. It occurred to me that VI scripting would be a great way to try making programs that build themselves using a sort of genetic algorthm. Something along the lines of: Place random block diagram objects. Wire up at random Can vi run? If not discard, if so, create many child VIs with slight modifications, or wholesale copying of parts of block diagram (c.f. gene duplication). Apply some sort of fitness function, perhaps testing for successful interfacing with instruments, or speed of execution. Select 'fittest' VIs, and repeat. It would be very interesting to see what came out of that. I don't know how easy it would be to implement, or whether you would need some sort of DNA style encoding of the block diagram to work with, but it looks like a fun challenge for someone! Cheers, Alex
  11. I have just discovered the "Automatically close VISA sessions" option. That was at the source of my problems. Cheers!
  12. Hi, I have been having big problems sorting out some serial communications issues in a very large program with parts dating back to Labview 3. Some intermittent comms errors started occuring after upgrading from LV8.5 to 8.6. After much headscratching it seems that the issue is due to the way VISA refnums are cleaned up when a VI stops running (even if others are still running in parallel). As far as I can see, in 8.5 and below if a VISA reference is opened, and a VI which uses it finishes running, the reference remains valid. In 8.6 however, if ANY VI which uses a VISA reference finishes, then the refnum is closed automatically. However this appears to behave differently on different computers. I'd be grateful if people with both version 8.5 and 8.6 could test the attached files. The first VI opens a VISA reference, waits for 2 seconds, then stops (without closing it). The second runs in a loop checking if the reference is valid. (With the option to close it if it is already open). I have tried this on two computers, on one of them (where we are having the problem), there is a difference in behaviour between LV8.5 and LV8.6. On the other (a laptop with no serial port, only USB, so I can't check the exact same VISA resource), there is no difference. It would be really helpful if you could do the following in both 8.5 and 8.6 1. Run "Valid refnum check(8.5).vi", and close the reference if it is already open. If you have no ASRL1 port try something else. 2. Run "Open VISA refnum with delay (8.5).vi", (with the same visa resource), wait for it to finish. 3. Tell me what happened (and which VISA resource you used if it wasn't ASRL1). Thanks very much. Alex
  13. I've just spent a very long time trying to debug something giving similar errors only in LV8.6 and not in 8.5. It seems that the way VISA references are opend and disposed of is different in 8.6. The situation was a single nonreentrant VI, BusCommand.vi, was called from various places in the main program, but internally it only set the serial settings (stop bits etc.) the first time it was run, and didn't properly link all its calls to the serial port using VISA reference wires. Put a probe on any VISA reference wires you have in your program to check that the stop bits etc. remain as you wanted them. Here is my description of the problem: I think the problem was with the behaviour of the VISA open node. You will notice that it has an "access mode" option. For some reason the default setting causes the serial port settings to revert to VISA defaults (n.b. NOT the same as those set in measurement and automation explorer), but only if no other VI is running which has an open VISA session which has been correctly configured. What was happening was that any call to read/write to the serial port would open a VISA session with the access mode set to VISA defaults, not MAX defaults. For reasons I don't understand it was ok if the serial settings had just been defined, but not when another vi which used BusCommand.vi was unloaded from memory (say a subpanel which called it was closed). This destroyed the VISA reference, which might happen half way through another BusCommand call. So the next "VISA open" used the default values (i.e. 1.0 stop bits).
  14. Hmm, it seems that some new abilities appear if SuperSecretPrivateSpecialStuff=True and SuperPrivateScriptingFeatureVisible=True are added to the labview.ini, including what looks like something to apply typedef changes. Has anyone had a go with these?
  15. I have a large program which makes heavy use of an enum typedef containing ~100 values. For some reason it is extremely slow to add new values to this typedef (any idea why would be much appreciated). Following this thread:http://forums.lavag.org/Programamtically-e...lues-t2761.html, I have made a simple script which adds new strings to the typedef, but I can't find a way to programatically apply the typedef changes afterwards. I don't have much experience with using VI server, and maybe have got lost in the maze of methods, but searching for "apply" in the class browser search didn't show anything. Any ideas? Cheers, Alex
×
×
  • Create New...

Important Information

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