Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/17/2013 in all areas

  1. Wait till you see LabVIEW 2013. It's so ahead of it's time it's nostalgic. Lucky I hacked NI and stole a snapshot build so I can show you all:
    3 points
  2. Hello all, I am not very active on the community here (though I'd like to change that), and just recently took the CLA after reading many of the posts on here. I found them incredibly helpful when preparing for the exam. I passed---and am now officially a CLA---but just barely. I scored 70/100---the minimum passing score. I had taken the practice CLA exam provided by NI, and carefully reviewed the provided practice exam solution. Though I didn't particularly like the sample solution, it was simple and possible to implement within 4 hours. During the exam, I used nearly the exact same architecture and felt that I completed more of anything you could think of than the sample solution did: I had more documentation, met more requirements, designed more "modules", etc. Either there is something I fundamentally don't understand about how my solution was different than the sample solution, or the sample solution would be a marginal pass (or a failure). My scoring breakdown was very similar to Daklu's: Style: 10/10 Documentation: 16/20 (Architecture/modules not documented adequately for developer to implement/complete functionality.) Req Coverage: 18/30 (Percentage of requirements covered = 60%.) Arch Development: 26/40 (Some "modules" not designed, others not clearly identified or modularized, hardware abstraction insufficient) I'm not sure what advice to give those yet to take (or re-take) the exam. If you passed the CLD, you will probably be fine on style. Don't lose points there. Provide sufficient documentation for how to finish what you started; I probably spent too much time implementing code rather than documenting how to finish implementation. Inevitably, there will be requirements that you think you have covered that you do not cover sufficiently by the standards of the graders, and you will lose points. Apparently I covered 60% of the requirements, though I recall writing [Covers: xxx] for nearly all of them (I guess the graders did not think the requirements were adequately met). It is really easy to get knocked on points for architecture development if you spend too much time implementing code. Design the architecture and document how to fill in the details. Filling in the details yourself (except for critical pieces of the architecture) is not worth the time expenditure... (the only category it might help is "requirements coverage", which can be covered sufficiently with documentation... in other words, good documentation can get you points on both "documentation" and "requirements coverage"). Best of luck to anyone who is trying to pass the CLA. If you are not prepared, you will not pass. If you are prepared and experienced, you might pass; success seems to be very hit-or-miss. Jared Kirschner | Electrical and Computer Engineer | Certified LabVIEW Architect | www.jaredkirschner.com
    1 point
  3. Strange, I thought it existed because of intense heat and pressure underground or something like that.
    1 point
  4. I do nearly all of FPGA work with the sbRIO line, so here are some of things I do when I have an FPGA VI that needs to run independent of the RT: Download the Bitfile and set it to Run when loaded -- There is an option to reset the FPGA VI on a reset of the RT, this is up to you are if you wish that. I do this mostly cause my projects require the FPGA to be active as soon as power is applied. If it was loaded with the RT, there is usually some delay, 20-30 for sbRIOs. I don't usually download the bitfile until I start testing outside of the IDE (you can run the FPGA VI independently in IDE easily) and for the final deployment. In the Open FPGA Reference I usually use the link to Bitfile option and do not select the Run option. -- This is a personal preference mostly. If you link it to the Build file or the VI, Your RT Vi will break if you change the FPGA VI. The reason I don't select the Run option is: I don't want the RT to reset my FPGA and I consider it an error, if the FPGA is not already running. To my knowledge the RT Build(the rtexe) always includes the FPGA Bitfile; but if you do not select the Run option, then the RT will simply connect to the FPGA. I don't use the Close Reference since the only time I "STOP" either the RT or FPGA is when power if removed. I open the Reference once and pass it to any subVI that needs it. I leave all my FPGA VIs as Re-entrant. The only time I would even consider using a non re-entrant VI in FPGA is if space is a premium (I have yet to even come close). I would like to note; that when deploying FPGA to multiple targets outside of the IDE, to my knowledge (LabVIEW 2012 and prior), the FPGA Target System Replication tool is needed as the System Configuration API does not, yet, support FPGA deployment.
    1 point
  5. Hi Daklu, To answer your questions in more of an order of execution: Open FPGA VI Reference This VI can either connect to an existing running FPGA VI, if it is already running, or download the bitfile it is linked to if it is not. Whichever ever linking mechanism you use the runtime behaviour is the same. Linking to a bitfile will always work but linking to a build specification or VI will query the project at edit time for which bitfile is the correct one to use (or break the VI if it still requires compilation). I have not had a use for the other options for run when loaded yet! I always stick to the open reference (which I think is what will take precendence when you run your RT VI anyway, the others must be something edit time related I think). In the open reference VI, if run when loaded is selected the FPGA VI will immediately start. If unselected it is not started until you manual start it using an invoke node. This can be used to set intial register values before the code starting. If the VI is already running through some other means (such as it is already running), these functions will return a warning at run time. Close Reference Your problem in 2 is probably related to the Close FPGA reference VI. If you right click you have an option to close or by default close and reset. This means the FPGA VI is reset (read aborted in standard LV speak) when we close the reference. If you want it to continue you should change this to just close. FPGA Image Deployment If you want the FPGA to run continuously independent of any RT code you either need a piece of RT code that you use to deploy it initially by opening a reference and closing it without the reset. Or you can actually flash the VI to the FPGA using the RIO Device Setup application which will be in your start menu. This will even cause the VI to persist over power cycles as well. FPGA Top Level Re-entrancy Any FPGA VI is re-entrant by default, this makes the most sense more of the time on FPGA. For the top level VI though it will make no difference as you can only ever run one top level VI on the FPGA at a time. As it is a VI though this is just going to apply if you wanted to call it as a subVI. I hope this helps clarify a few points and I think covers your questions. Cheers, James
    1 point
×
×
  • Create New...

Important Information

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