jgcode

QUOTE (LV_FPGA_SE @ Oct 4 2008, 02:41 AM) Hi LV_FPGA_SE Is there any caveats to running dynamically called VIs on LV RTOS. My main question is with respect to memory allocations. I am worried that dynamically called vis could chew up contiguous memory for large arrays. At present I initialise my arrays from bootup and am very cautious in not dynamically increasing their size or making copies. Especially when the application has to run for days/weeks/year I have not have the need to use dynamic VIs on RTOS - is there a benefit to using them? The main one I could see if it freed up resources - but does this actually happen? Cheers Jon

Thanks for the responses guys :beer: Cheers for the links aswell. That VI that will work a treat especially since its XP & Vista compatible. Being a widely distributed LabVIEW product - I am still interested to know if anyone else knows how VIPM works around accessing Program Folders. Cheers JG

I get two "containers" for a LV application in my taskbar in VISTA (XP only has one which is good). It has a splash screen then launchers the main vi. One container is redundant the other maximises/minimises the application Any ideas how to clean this up. HideRootWindow=True has been tried but does not work. Cheers JG

How are developers handling installing on VISTA? I normally like to store private files in the data folder @ C:\Program Files\<application>\data or similair. However, the application can not access them with out ticking the checkbox in the executable's properties and turning on administrator rights. Is there any way to get around this on NI installer? I have also noticed that VIPM does not have this enabled and it works! Any suggestions on what to do or any pointers to any information? There are a few topics on Windows Vista here and here. NI whitepaper on virtualisation is here and the parent page here Cheers JG

QUOTE (jlokanis @ Sep 12 2008, 08:57 AM) PJM had a post with a blog reference that did the text/button changes. Whether it fits the other requirements? I think it came up in the - Sequence structure is bad / Invent the new dialog challenge - series of posts. Worth asking him/checking out. Cheers JG

QUOTE (Cloedu @ Aug 25 2008, 06:00 PM) Thats how I was taught in school.

Following on from the Tom's paper chase and internal NI certificaton - this question is an off shoot that I guess only NI posters can answer but is open for discussion: Do the exam markers actually sit through the NI Courses :question: One example being I copied NI style from the Int course when I sat the CLD, and got picked up on it. [More specifically - the use of coercion dots for the variant in the queue datatype cluster when making a wrapper VI for the display queue]. I did not do the data-to-variant conversion but nor does NI in their course - so I thought it was ok. But then they penalise for it in the exam - I find that very hypocritical, inconsistent & annoying. :headbang:

QUOTE (Michael_Aivaliotis @ Feb 19 2007, 05:14 PM) Ahh..my questions answered and I didn't even need to start a thread..thanks guys :beer: LAVA

QUOTE (jgcode @ Aug 20 2008, 07:01 AM) Looks like I will have to eat my shorts... Guess what turned up in the mail today.... ...8.6 I am humble enough to do a big shout apology to NI

QUOTE (LV_FPGA_SE @ Aug 22 2008, 07:45 AM) With a name like LV_FPGA_SE I was looking forward to your explaination ! :beer:

QUOTE (Aristos Queue @ Aug 22 2008, 06:17 AM) While I agree your other comments but..... I don't think a state machine should be compared to stacked sequence at all For the following reasons (off the top of my head): a) It is a design pattern b) It increases readability (with an enum) - i would say that this is the most important point, seeing a large part of coding is about reading esp when doing maintainence/upgrades c) Dataflow is not backwards as with sequence structures, as it uses USR/SR d) It logic is scalable - although it may be sequential in operation now, later on states can be added, and logic does not have to be sequential e) Its design pattern is scalable - without a doubt a SM + FGV (or whatever nonclementure you will to use) is one of the best design pattern I have found for creating a module (following the rules of encapsulation, loose coupling, high cohesion etc..)

QUOTE (jgcode @ Aug 21 2008, 01:46 PM) QUOTE (shoneill @ Aug 21 2008, 03:50 PM) Or use the OpenG versions with error inputs and outputs. You DO wire the erros terminaly, right? It's a better solution than sequence structure and needs less space on the diagram..... Shane. I know this topic has been moved but... Dude - I know Open G is available as I mentioned it. Its not a better solution - its a different solution. And no, if you are already using the flat sequence then it doesn't have to take up more space

QUOTE (mross @ Aug 22 2008, 01:46 AM) Another great point that FPGA uses them alot. Check out the demos in Example Finder, if you can, and you will see that when you are programming nodes on the FPGA, flat sequence structures are used alot.

QUOTE (Raymond Tsang @ Aug 21 2008, 08:53 AM) The default buffer for a strip chart is 1024. That is hardly huge. I have tried passing 50-100K pts without struggling. Obviously the user can only see so much resolution anyway! What is your definition of huge? Sample rate x "time needed to be displayed" = on-screen buffer size Do you need to write a point at a time to the screen or can you update the screen in chunks? Do you need to write every point to the screen or can you decimate the array?

QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this)

QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this) b) QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) .....I've found it much easier to start with a more complex framework and pare down what I don't need than to try to add state functionality after I've already started coding. Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this) b) QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) .....I've found it much easier to start with a more complex framework and pare down what I don't need than to try to add state functionality after I've already started coding. Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this) b) QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) .....I've found it much easier to start with a more complex framework and pare down what I don't need than to try to add state functionality after I've already started coding. Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this) b) QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) .....I've found it much easier to start with a more complex framework and pare down what I don't need than to try to add state functionality after I've already started coding. Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this) b) QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) .....I've found it much easier to start with a more complex framework and pare down what I don't need than to try to add state functionality after I've already started coding. Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this) b) I QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) .....I've found it much easier to start with a more complex framework and pare down what I don't need than to try to add state functionality after I've already started coding. Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this) b) I like to use a QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) .....I've found it much easier to start with a more complex framework and pare down what I don't need than to try to add state functionality after I've already started coding. Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this) b) I like to use a single QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) .....I've found it much easier to start with a more complex framework and pare down what I don't need than to try to add state functionality after I've already started coding. Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this) b) I like to use a single frame QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) .....I've found it much easier to start with a more complex framework and pare down what I don't need than to try to add state functionality after I've already started coding. Amen to that. QUOTE (BobHamburger @ Aug 21 2008, 12:30 PM) As far as I'm concerned, I wouldn't miss it if the sequence structure were completely removed from LabVIEW. IMHO, it simply has no place in the dataflow-dependency paradigm. No! Sequence Structure - I see your point RE: data flow. But this structure seems to have been quite a standard in LV5-6 code (along with globals ) before everyone picked up the design pattern ball and ran with it. I personally would hate to see this be unsupported if I had to bring up LV5/6/7 into LV8+. Flat Sequence - definately not. a ) There are enough NI VIs that are not sequence with the error cluster (timers etc...) to warrent this (I know Open G have fixed this) b) I like to use a single frame for

QUOTE (LV_FPGA_SE @ Aug 20 2008, 09:56 AM) Cheers for that - much appreciated :beer: - ni.com still seems to be down tho

QUOTE (Antoine Châlons @ Aug 19 2008, 10:47 PM) WTF! Where do I sign up....??

QUOTE (Norm Kirchner @ Aug 19 2008, 07:58 AM) Who in the world has RT 8.6? I want it! Can you download modules now? I hope so - otherwise our Dev Suite subsription won't be here til Q3 - which usually turns into Q4. Don't know abut around the globe - but they are so slow in Australia! Can you download it? (Can't get into ni.com for some reason as at writing this, so I cannot check)

QUOTE (LV_FPGA_SE @ Aug 18 2008, 08:18 AM) So certification = experience?

Another reason for certification: [At least in Australia] NI requires a certain number of certified employees (among other things) in order to distinguish your Alliance member status This in turn relates to margins, discounts, free software etc...

QUOTE (ChrisClark @ Aug 18 2008, 01:44 AM) Hi Chris Depends on the LV version as well LVOOP - No (although AQ has pointed out not for long - search thru his latest postings on LV8.6) Endevo switched to using LVOOP in 8.5 so anything pre- will work on the RT Sciware doesn't used LVOOP so it will be good! Probably your best bet for 8.5. DQGOOP - have not used but apperently based on queues so it should work. See http://forums.lavag.org/LV85-OOP-and-Embedded-Targets-t10954.html' target="_blank">here as this was asked before in the OOP forum Once you make a decision get it touch with the supplier for more info. Cheers JG

QUOTE (Yair @ Aug 18 2008, 01:06 AM) Cheers mate! :beer:

QUOTE (crelf @ Aug 18 2008, 04:37 AM) This is a awesome point and a lesson I just recently learnt and realised the value of! Sell the solution to the problem - not the hardware/software Customers who don't know (e.g. about NI/LV), don't care, they just want their problem solved!

QUOTE (crelf @ Aug 17 2008, 03:11 AM) I agree! I could see this topic going nowhere. Good call. QUOTE (crelf @ Aug 17 2008, 03:11 AM) Yes, I would absolutely look at grades and references, amongst a gah-zillion other things, including (often most importantly) their interviews. Candidates might look very similar on paper (as your example suggests), but, in my experience, there are never so similar in an interview that I would ever have choose one over another due to their grades alone. I admit the examples were out-there. I was wrong to say with all else being equal as in reality and from experience as you pointed out this is not the case. I guess more correctly the point I would like to get across is that what people look like on paper: whether exp/certs/quals/refs/comm skills and personality (from cover letter) is going to stand them in good steed to get lined up for an interview as the CV is the first impression of the candidate on the interviewer, and is usually the first step in applying for a job. And although I have never interviewed anyone, from talking to interviewers when they have a stack of applications and they need to sort out the shortlist from the circular filing cabinet - they are just merciless e.g. spelling mistake: in the bin. QUOTE (crelf @ Aug 17 2008, 03:11 AM) In summary, yes - certifications, amongst many many many other things, can be used when differentiation between job candidates. Agreed. At the end of the day certification is important to me whether for the piece of paper alone or for validation of my skills/effort.