jgcode

Just to clarify: I just posted above an example of what I currently do - only. Cheers -JG

Hi Roger That sounds great. You can start by signed up at SourceForge (see Daklu posts above). With respect to namespacing, I have been encapsulating all releases in a Top Level Library that gets renamed during the distribution e.g. so "StateDisplay.lvlib" source would be release as "StateDisplay_company_lib_state_display.lvlib" (following VIPM namespacing syntax). This has worked out great for all my releases with respect to namespacing and upgrading etc... except I am having some issues with the palette I have not yet been able to resolve. Cheers -JG

Yer, I have seen the layout change internally and I don't like that. But you can't have your cake and eat it too. Whilst, a .llb layout is very handy for relative calls, encapsulating libraries and classes etc... inside the build (exe) is far more valuable IMHO. However, its nice that you have the option to use the 8.x Build Model. Otherwise porting up all my older code would be a nightmare.

I don't think this is 100% guaranteed in the 2009 Build Model. For example if you have a VI at C:\<src tree>\project\subVIs\*.vi and you do a build then Link to D:\<where-ever>\*.vi then do a build Then the internal hierarchies will be different. I think the best\safest way is a static reference. (Granted, why would you do the above - but it is still an edge case to consider, there maybe others too)

I know exactly how you feel! I love LabVIEW but it can be slow and prone to so many crashes! Especially I find from using Classes and Libraries! Then you have to reboot it, and I have/need all the modules installed so that takes ages on my (mid-level) PC. Then I have to solve the complex time algorithm of: Do I load the palettes at startup or wait until I activate Quick Drop? As far as I know you can't really, its tied in too heavily to the Project. All the target info and access to the modules/IO nodes, config adding hardware etc... come from the Project I have never tried it but I am guessing no tho. As I am pretty sure you would need the target in memory and be working from it or LabVIEW wouldn't have a clue your target is RT or FPGA and not just a PC - so all the RT or FPGA specific stuff would break and you probably would be able to access it from the palette. But like I said, I have never tried... ...maybe I will later just to see...

That one really annoys me! Damn that is nothing! - anyone here do FPGA? Check this out: <object id="scPlayer" width="793" height="549"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c0ec32fc-9d1f-4c99-bc81-0b0e3c3fdd66/jingswfplayer.swf"></param>'>http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c0ec32fc-9d1f-4c99-bc81-0b0e3c3fdd66/jingswfplayer.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c0ec32fc-9d1f-4c99-bc81-0b0e3c3fdd66/FirstFrame.jpg&containerwidth=793&containerheight=549&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c0ec32fc-9d1f-4c99-bc81-0b0e3c3fdd66/FPGA%20is%20slow.swf"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c0ec32fc-9d1f-4c99-bc81-0b0e3c3fdd66/"></param>'>http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c0ec32fc-9d1f-4c99-bc81-0b0e3c3fdd66/"></param> <embed src="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c0ec32fc-9d1f-4c99-bc81-0b0e3c3fdd66/jingswfplayer.swf" quality="high" bgcolor="#FFFFFF" width="793" height="549" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c0ec32fc-9d1f-4c99-bc81-0b0e3c3fdd66/FirstFrame.jpg&containerwidth=793&containerheight=549&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c0ec32fc-9d1f-4c99-bc81-0b0e3c3fdd66/FPGA%20is%20slow.swf" allowFullScreen="true" base="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/c0ec32fc-9d1f-4c99-bc81-0b0e3c3fdd66/" scale="showall"></embed> </object> I also: Use a lot of Classes and Libraries Use Integrated SCC with the LabVIEW Project Often use multiple targets All which slows it waaaay down.... I would like to add up all the time during a day with which I get the spinning blue circle of death. I think it would be quite significant. Maybe we need a LabVIEW Project support group? I'll start: "Hi my name is JG, I am addicted to using the LabVIEW Project, even tho I know its really bad for me....."

Hi Ton Thank you for your reply. Sorry I could not post sooner as I was forced offline Anyways, I have posted the code to the NI Thread if you wish to have a play with it. Attached are the dependencies when I drop the XControl from the palette and it appears broken on the FP. Please note the library is distributed as locked (hence the locked glyph) and it has been loaded (which is good I guess!). And also the errors Cheers -JG

[Cross-posted to ni.com] Version: LabVIEW 2009 Howdy! I have having the following issue: This distribution contains an X control that when dropped from the palette breaks its linkage (see video), the palette was created manually. I also have tested selected it from disk: "Select a Control..." and I get the same broken image So it seems the distribution has been "corrupt" somehow?? Note that the .xctl sits in another Library (used to namespace the distribution) When I put this Library in memory the broken X Control relinks (see video). If I save to disk and reopen without the library in memory the x control seems ok. The Libraries are locked and there are no dirty dots to suggest a linking issue. I used the NI Build Spec to create the distribution, renaming the Namespace Library only. Does anyone know why this could be happening? <object id="scPlayer" width="950" height="691"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/199eebe5-9fe1-495e-9631-d30863f67f6b/jingswfplayer.swf"></param>'>http://content.screencast.com/users/jgcode/folders/LabVIEW/media/199eebe5-9fe1-495e-9631-d30863f67f6b/jingswfplayer.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/199eebe5-9fe1-495e-9631-d30863f67f6b/FirstFrame.jpg&containerwidth=950&containerheight=691&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/199eebe5-9fe1-495e-9631-d30863f67f6b/X%20Control%20Palette%20Bug.swf"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/199eebe5-9fe1-495e-9631-d30863f67f6b/"></param>'>http://content.screencast.com/users/jgcode/folders/LabVIEW/media/199eebe5-9fe1-495e-9631-d30863f67f6b/"></param> <embed src="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/199eebe5-9fe1-495e-9631-d30863f67f6b/jingswfplayer.swf" quality="high" bgcolor="#FFFFFF" width="950" height="691" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/199eebe5-9fe1-495e-9631-d30863f67f6b/FirstFrame.jpg&containerwidth=950&containerheight=691&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/199eebe5-9fe1-495e-9631-d30863f67f6b/X%20Control%20Palette%20Bug.swf" allowFullScreen="true" base="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/199eebe5-9fe1-495e-9631-d30863f67f6b/" scale="showall"></embed> </object>

Known issue with the 1.1 release Class must be saved to disk The Class icon must have been opened at least once in the Icon Editor. The latter is a weird bug in the Icon Editor API posted here but I have come up with my own work around. So I have fixes for both and will release an update soon as well as some new features. Cheers -JG

How many pixel incrementations did it take to figure that one out! Good Job

No probs. What absolute path are you using? I am sure you could still get to it, but you would have to be using the correct one. The easiest way to do this is to use the reference and path property node to write it to the screen so you can see it. Then you could try that path in accessing the VI (just to test it). The 9.0 build model is a similar structure to whats on disk however, depending on your linking it can change. Plus the .exe "folder" will be in there somewhere to. Using a reference is by far the safest. I haven't had to deal with resolving paths for a while now

Hi Ton It is the forum software that is creating the hypertext. The only difference between the two screenshots is that I moved a quote around. The forum software removed my pictures, replaced them with the hypertext then appended them to the bottom. So its not the case that "any attached imaged that is not used in the post is automatically shown", they were included originally. Hope that makes more sense, Cheers -JG

I have seen remapping to other events, if you edit clusters. Are you referring to what Jim has posted here?

Whats hockey?

What does that mean? Does it rain often in Montreal? (Home of the great GSP - you didn't go to UFC 113 @ the Bell Centre did you?)

Ok this sounds really exciting... This is because I am trying to release packages now that contain reusable class that I can use in my projects. I am I seeing massive performance increments (not CPUs stuff - I mean in respect to my time in rolling out a project). There is a lot of work setting things up, but the payback can be huge. So I can see this as really beneficial to the community. No point reinventing the wheel - lets get together. As soon as I read this I thought OpenG too. I think anything that can improve LabVIEW is a good thing, and who knows down the track they may get natively implemented like some OpenG functions have in the past. I think OpenG would have the credibility and the backbone to roll this out, so definitely look there first (IMHO too) Here is a list of things I am working on at the moment: (I have decided to start with 2009 for this, there is just so much more I can do there then say 8.2, so I don't see the point) Data Class (objects that have LV datatypes with get and set methods so I can send/store/manipulate data as objects) Circular Buffer (stores generic LV Object, but I make wrappers for common Data Classes (E.g 1D DBL) so I don't have to convert in my code) Counter Error Logger Timers Window (Front Panel) Settings File IO Manager (creates a file with a header so file versioning is easy, extend to implement e.g. a config file to manage sections and reading/writing) File IO Interface Various UI Effect Making a plugin Run Time Menu, that is also linked to buttons (e.g. enable button enable RTM item, turn button On, check RTM item; select an enum value, check one item in a list in a RTM submenu etc..) Now, none of these maybe of interest, but that is just some stuff I am up too. I like LVClasses so I am down for pretty much anything. PS - What is with the name?

Hi Mods, I have noticed the following about quotes affecting the embedding of images in posts. Not show stopping but I though worth mentioning if not known: With no quote after my images I can display my images exactly where I want to in the post: When I add a quote to the mix after the images, then I get a hypertext reference where I wanted my images and now my images are added at the bottom of the post. Cheers -JG

Collaboration sounds like a smashing idea! I have been playing around with Layers using the Icon Editor API, so its all 2009. But there may be some stuff there that would be of benefit. We should definitely have a chat offline. Getting to the class by the Name property works, whereas the Path property returns a blank when the class is not saved and the Open VI Reference for the Control returns the error 1004 The name mashing is still the same as it is still similar to the previous thread. I guess it only matters if you are reading the class off disk and not in memory, then it would be saved anyway so use the Path. It all seems so Basic I Core 1 'ish now.... vs @ Francois Not at all...more than one way to skin cats. I learnt something and that is never a bad thing.

You knowledge of the force class is strong Although I always want to know how to do it myself.... I think its time to get more intimate with your API (I have downloaded and looked at it before, just so you know). Do you recommend this over the other method? I remember AQ mentioning about the class being in memory before getting a reference to the .ctl etc... Kudos!

Howdy! I use this method of getting the .ctl reference of a class (posted by some of my smashing friends here at LAVA ). However, when the class is not saved I get error 1004. So my question is... ...Is there any way I can get a valid reference when the Class is not yet saved? Cheers -JG

Cool - did you get it to go?

Ok, I have been seeing this for a while. In PMs and now posting. Glad? to see others have same problem (hey - at least that means I am not alone!) Mods Is this an IPB Known Issue? Is there a workaround? Cheers -JG

Just drag and drop the VI you want to call dynamically into the Static VI Reference and it will show the icon for that VI. Now you have a reference to that VI. Now use a Property Node to get the VI's Path so that whether you call this in Dev or RT it will be the correct path. Hope that make sense?? Cheers -JG

Deal! Give this a shot and let me know how you go. [edit] In my browser the above picture is distorted (stretched)? Just right click and select Open In New Window to view in native resolution [/edit]

Hi Val I risk stating the obvious... (so don't shoot me down ) The VI paths change between build models (8.x vs 9.0). It sounds like your inclusions are fine How do you resolve the VI paths so that you get a reference to them? I tend to use a Static Reference now-days rather than trying to resolve the valve of the path data type (based on Dev vs RT) so it doesn't matter what the internal structure of the 9.0 build is. -JG PS - I like to create a VI Tree.vi and stick all dynamic VIs in there so I only have to Always Include one file - so I don't forget to add new ones to the build spec.