Eugen Graf Posted January 23, 2009 Report Share Posted January 23, 2009 Sorry, if I'm wrong, but I think that scripting is not necessary for LabVIEW (I, personnaly don't use it). You can generate and control code automatically, but can't use that in executables. Which advantages does it have? Do you have some VIs for automaticaly generating? Really? Or You want only to improve LV IDE? Quote Link to comment
Neville D Posted January 23, 2009 Report Share Posted January 23, 2009 QUOTE (Eugen Graf @ Jan 22 2009, 02:24 PM) Sorry, if I'm wrong, but I think that scripting is not necessary for LabVIEW (I, personnaly don't use it). You can generate and control code automatically, but can't use that in executables. Which advantages does it have? It can be very useful to write tools for code development or automate some coding bits that you find yourself doing over and over. For example the Tunnel wiring tool. Just because you haven't yet found a use for it doesn't mean it isn't useful. N. Quote Link to comment
Antoine Chalons Posted January 24, 2009 Report Share Posted January 24, 2009 QUOTE (Eugen Graf @ Jan 22 2009, 11:24 PM) Sorry, if I'm wrong, but I think that scripting is not necessary for LabVIEW (I, personnaly don't use it). You can generate and control code automatically, but can't use that in executables. Which advantages does it have?Do you have some VIs for automaticaly generating? Really? Or You want only to improve LV IDE? If - like Ton said - you make the difference between scripting and private methods then yes. But private methods come with scripting and can be helpful in your applications Quote Link to comment
Tomi Maila Posted January 24, 2009 Report Share Posted January 24, 2009 QUOTE (Eugen Graf @ Jan 23 2009, 12:24 AM) Sorry, if I'm wrong, but I think that scripting is not necessary for LabVIEW (I, personnaly don't use it). One real use-case for scripting is automatic code generation. It is common that complex protocols definitions are in a machine readable format such as XML. To implement the latest version of the protocol, you could generate automatically the required code from the XML specification. Or this is true for other programming languages, but for LabVIEW it is impossible without scripting. Hence LabVIEW developers need to manually write complete protocol libraries and manually update changes and bug fixes in protocol libraries whereas developers in other programming languages can simply execute the code generation script to generate the latest version of their protocol library. So maybe you would not use LabVIEW scripting so often in your actual production code, but you could use LabVIEW scripting to generate the production code. Quote Link to comment
Grampa_of_Oliva_n_Eden Posted January 24, 2009 Report Share Posted January 24, 2009 I'll add an arguement for scripting I have an app that uses SCRAMNet and maps 2 Meg of memory for up to about 50 devices. This mapping is documented in a standard form. The mapping can change when engineerings decides it needs re-mapped. It took two developers 3 days to re-map the data fields the last time there was a major change. I wrote Script that was capable of redfining the clusters associated with the mapping and it worked on machine at home. At work it gave me an insane object error while doing the demo for my boss.... I abandoned scripting. Ben Quote Link to comment
LAVA 1.0 Content Posted January 24, 2009 Report Share Posted January 24, 2009 QUOTE (mike_nrao @ Jan 22 2009, 02:02 PM) I think we interpret NI Labs differently. When I read "aren't quite ready for release" and I see a list of "graduates" along the side of the page, I'm led to believe NI Labs stuff will soon (maybe less than one year) be available. Judging from the discussions on the NI Labs forums, there doesn't appear to be much product evolution taking place. This could mean people aren't using NI Labs, or people are not giving feedback, or the product is fairly mature and people are happy. To clarify, NI Labs contains both new features that will be available soon in the product and are prereleased on NI Labs, but it also contains projects and ideas that are being evaluated and may never make it into the product, or will look very differently when released in the future. So NI Labs does serve several different purposes in that regard, but most content that is chosen for NI Labs falls into one of these two categories. Prerelease of an upcoming feature with little change in API Evaluation and feedback of a new idea, concept, or feature that may or may not make it into a released product. We just don't always say which of these two you are looking at. In general I do not recommend building any kind of products based on NI Labs content, unless you have verified with NI the future availablity and interface of the content you are considering using. Quote Link to comment
David Wisti Posted January 24, 2009 Report Share Posted January 24, 2009 I for one would purchase a license for scripting if it ever gets released as a product. Releasing it as an extra price adder for those that need/want scripting should keep the support cost for NI to a minimum compared to releasing for everyone. Quote Link to comment
crelf Posted January 24, 2009 Author Report Share Posted January 24, 2009 QUOTE (David Wisti @ Jan 23 2009, 12:04 PM) Releasing it as an extra price adder for those that need/want scripting should keep the support cost for NI to a minimum compared to releasing for everyone. True. Quote Link to comment
Rolf Kalbermatter Posted February 21, 2009 Report Share Posted February 21, 2009 QUOTE (neBulus @ Jan 22 2009, 09:35 AM) The patent for LV has is is due to run out (unless something happened since I last looked). There are more than a handful of patents that cover LabVIEW. Some quite new and some quite old. One of the first patents issued for LabVIEW run out one or two years ago but NI applied for extension and it was granted. QUOTE Keeping Scripting limited NI can maintain its control over enhancements to LV and force anyone attempting to make a better version of LV (LV writtien in LV?) they will have to work for it. I think this is one valid and actual reason they do not feel like opening it up completely. Note there seem to be people with access to it outside NI, but one needs to have a very compelling reason for that. Another one is that it has still quite a few sharp edges and trap falls. Also it does often not seem to be engineered in any specific way but sometimes looks more like ad-hoc methods and properties sprinkled across the object hierarchy of LabVIEW like it got added whenever an internal tool developer found a new hook he needed to create the next LabVIEW tool feature or addon. Sometimes obvious methods are missing that seem logical in conjunction with others that do exist. Not in the sense that one requires the other but more in why implement a method for a specific object but not for others where it does make just as much sense. Also I have a few times gone into it to solve a specific problem looking and searching for the right methods and properties only to find out that the key method threw a not supported error. Yes going to the next LabVIEW version often remedies that error but at the same time things tend to break regularly when upgrading scripting code to a new LabVIEW version. QUOTE (neBulus @ Jan 23 2009, 07:13 AM) I'll add an arguement for scripting I have an app that uses SCRAMNet and maps 2 Meg of memory for up to about 50 devices. This mapping is documented in a standard form. The mapping can change when engineerings decides it needs re-mapped. It took two developers 3 days to re-map the data fields the last time there was a major change. I wrote Script that was capable of redfining the clusters associated with the mapping and it worked on machine at home. At work it gave me an insane object error while doing the demo for my boss.... I abandoned scripting. This sounds more like an argument against releasing scripting right now. But a more realistic solution would be to write a flexible driver in the ways of Tag based addressing, where you do use the Device Names/Tag Names in your LabVIEW code and on start up load that list into a Vi that can do the TagName<->MemoryAdress translation. It's a bit of work to do that in a good way but hardly more than writing a tool that can read your address list and change all the VI code using scripting. Rolf Kalbermatter Quote Link to comment
Grampa_of_Oliva_n_Eden Posted February 21, 2009 Report Share Posted February 21, 2009 QUOTE (rolfk @ Feb 20 2009, 02:02 AM) ...This sounds more like an argument against releasing scripting right now.But a more realistic solution would be to write a flexible driver in the ways of Tag based addressing, where you do use the Device Names/Tag Names in your LabVIEW code and on start up load that list into a Vi that can do the TagName<->MemoryAdress translation. It's a bit of work to do that in a good way but hardly more than writing a tool that can read your address list and change all the VI code using scripting. Rolf Kalbermatter Thanks for the comments Rolf. Well right up until the crash is was an arguement for scripting. The translation had to happen fast* so I did benchmarks to determine the "optimum" code struture to accomplish the task. Ben *I was logging the entire memory space of SCRAMNet at up to 1KHz which roughly translates as 50,000 "channels" at 1KHz. So if the customer every really wanted to crank up the acq rate, it COULD be trying to log at 50MHz. ( In reality I don't think anyone would actully crank it up that high since I made sure they had to "work to cause that problem". Additionally, most of the memory space offered via SCRAMNet was static so I only had service interupts for values that changed. A latter version of this app will be spread across multiple CPU to "divide and conquer"). Quote Link to comment
Michael Aivaliotis Posted April 11, 2009 Report Share Posted April 11, 2009 This looks like the Patent for VI Scripting. SYSTEM AND METHOD FOR PROGRAMMATICALLY GENERATING A SECOND GRAPHICAL PROGRAM BASED ON A FIRST GRAPHICAL PROGRAM Quote Link to comment
Grampa_of_Oliva_n_Eden Posted April 11, 2009 Report Share Posted April 11, 2009 QUOTE (Michael Aivaliotis @ Apr 10 2009, 04:52 AM) This looks like the Patent for VI Scripting. Thank you for that link Micahel! The parts I read and associated figures were educational. The up-cast and down cast operators neve made much sense to me but looking at the hand drawn images make more sense now. Ben Quote Link to comment
ShaunR Posted April 12, 2009 Report Share Posted April 12, 2009 QUOTE (David Wisti @ Jan 23 2009, 06:04 PM) I for one would purchase a license for scripting if it ever gets released as a product. Releasing it as an extra price adder for those that need/want scripting should keep the support cost for NI to a minimum compared to releasing for everyone. Yeah. Just what I need. Another license key to add to the 25 I already have! Quote Link to comment
TobyD Posted April 15, 2009 Report Share Posted April 15, 2009 QUOTE (ShaunR @ Apr 11 2009, 05:07 AM) Yeah. Just what I need. Another license key to add to the 25 I already have! If you sign up for the developer suite you get a single license key for everything - including add-on packages. Then the only headache is remembering which products you actually have. Quote Link to comment
ShaunR Posted April 16, 2009 Report Share Posted April 16, 2009 I do have a developer suite which on a SSP, and no. I don't get a single license for all the packages. Apprently thats only for a volume license agreement...I've tried! Quote Link to comment
TobyD Posted April 16, 2009 Report Share Posted April 16, 2009 QUOTE (ShaunR @ Apr 14 2009, 11:56 PM) I do have a developer suite which on a SSP, and no. I don't get a single license for all the packages. Apprently thats only for a volume license agreement...I've tried! You're getting screwed. I am not on a volume license and I have a single key that works for everything that comes with the LabVIEW Developer Suite + Automated Test Option + Machine Vision Option. Quote Link to comment
Val Brown Posted April 17, 2009 Report Share Posted April 17, 2009 QUOTE (TobyD @ Apr 15 2009, 11:28 AM) You're getting screwed. I am not on a volume license and I have a single key that works for everything that comes with the LabVIEW Developer Suite + Automated Test Option + Machine Vision Option. Ditto for me. Quote Link to comment
shoneill Posted April 17, 2009 Report Share Posted April 17, 2009 QUOTE (Val Brown @ Apr 16 2009, 01:22 AM) Ditto for me. Same for me too. Shane. Quote Link to comment
ShaunR Posted April 17, 2009 Report Share Posted April 17, 2009 Hmm. Not sure about getting screwed (it's not that expensive) but I have complained many times - every time I upgrade in fact. That said, I'm not talking about the Serial Key (I've got one of those that covers everything) I'm talking about the activation codes since the development PC isn't connected to the internet I have to phone up NI and (always seems to be a girl called Sam.....lol) they look my details up and maybe a day later 25 e-mails come through with the activation codes which I then have to get to the other machine. Real pain in the proverbial 2-3 times a year especially if they miss hear the computer ID or I haven't upgraded all the items! Quote Link to comment
Val Brown Posted April 17, 2009 Report Share Posted April 17, 2009 QUOTE (ShaunR @ Apr 16 2009, 01:11 PM) Hmm. Not sure about getting screwed (it's not that expensive) but I have complained many times - every time I upgrade in fact.That said, I'm not talking about the Serial Key (I've got one of those that covers everything) I'm talking about the activation codes since the development PC isn't connected to the internet I have to phone up NI and (always seems to be a girl called Sam.....lol) they look my details up and maybe a day later 25 e-mails come through with the activation codes which I then have to get to the other machine. Real pain in the proverbial 2-3 times a year especially if they miss hear the computer ID or I haven't upgraded all the items! I do all of that online in one operation so I'm not sure what's happening on your system except, perhaps, it's not online? Quote Link to comment
crossrulz Posted April 17, 2009 Report Share Posted April 17, 2009 QUOTE (ShaunR @ Apr 16 2009, 04:11 PM) That said, I'm not talking about the Serial Key (I've got one of those that covers everything) I'm talking about the activation codes since the development PC isn't connected to the internet I have to phone up NI and (always seems to be a girl called Sam.....lol) they look my details up and maybe a day later 25 e-mails come through with the activation codes which I then have to get to the other machine. Real pain in the proverbial 2-3 times a year especially if they miss hear the computer ID or I haven't upgraded all the items! You can get the activation codes over email from another computer. I've done the exact same thing and have the codes within an hour, usually 10 minutes. Quote Link to comment
Jim Kring Posted April 18, 2009 Report Share Posted April 18, 2009 To get this back on topic, I think that we should all wear tie-die shirts to NIWeek that say, "Legalize Scripting". Quote Link to comment
Val Brown Posted April 18, 2009 Report Share Posted April 18, 2009 QUOTE (Jim Kring @ Apr 16 2009, 05:14 PM) To get this back on topic, I think that we should all wear tie-die shirts to NIWeek that say, "Legalize Scripting". How about "Release Scripting!"? QUOTE (Val Brown @ Apr 16 2009, 07:42 PM) How about "Release Scripting!"? ...or "Liberatus Scriptus" Quote Link to comment
crelf Posted April 18, 2009 Author Report Share Posted April 18, 2009 QUOTE (Jim Kring @ Apr 16 2009, 08:14 PM) I think that we should all wear tie-die shirts to NIWeek that say, "Legalize Scripting". I have a feeling that you'll be able to use your t-shirt money for something else by then :ninja: Quote Link to comment
ShaunR Posted April 18, 2009 Report Share Posted April 18, 2009 Nope. It's not online. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.