Ed Dickens
-
Posts
224 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Ed Dickens
-
-
Name: RCF Plugin - Align Terminal Labels
Submitter: EdDickens
Submitted: 30 Jul 2009
Category: *Uncertified*
LabVIEW Version: 8.6
Version: 1.0.0
License Type: BSD (Most common)
Make this available on the VI Package Network?: Yes
Introduction
Invoking this plugin from the block diagram allows you to auotmagically align the selected terminal labels to the specified position. If no terminals are selected, all terminal labels will be moved to the specified position. It has individual selections for Controls and Indicators.
This currently does not support any front panel aligning.
Hope you find this useful. Let me know if you want more positions or front panel support.
Steps to Complete
This plugin is packaged for use with the JKI VIPM. Download the VIPM package, right click and select "Add To VIPM Library", then select the "Add To Library & Install" button from the dialog that opens. You'll need to restart the JKI RCF to use the plugin.
-
Better would be even if that menu was in the front panel too and of course disabled for controls that do not have an event associated.
But for now this is something only NI can do in their LabVIEW C(++) code.
Rolf Kalbermatter
That was part of it as well.
I already had the Initialization code done when I realized I couldn't get the "TextLables" property for an Event Straucture. It looks to make sure that the selected item is either a panel control OR a diagram terminal AND that there's an Event Structure or the menu won't show. I like the idea doing the search at this stage so the menu only shows if there's a linked Event Frame.
-
What you can do is get all frames, then for each frame get all objects, cast all objects to Control Terminal ref and keep the refs that do cast and get the terminal label text. Now you have a list of terminal refs against frame refs by terminal label text. If you search for your control by label text you can get its Terminal ref and also the ref of the frame that it belongs to.
I guess I should have explained why I'm building the plugin.
If the terminal is in the Event Frame, you can just double click the control and it will bring you to the correct Event Frame. Don't need a plugin for that. And if you're already looking at it in the code, you're already there as well.
Sometimes the terminal is not in the Event Frame it's linked to, and that's was going to be the real purpose of this plugin. Say you double click a control and it gets highlighted in the code, but it's not in the Event Structure, but you know there's an Event configured for it. You can now right click the terminal and select "Find Event Case" and automagically you're looking at the correct Event Frame.
If I'm reading what you're suggesting correctly, it will only work if the terminal is in its Event Frame. Good solution if that use case will work for you though.
Thanks
-
What did you have in mind?
I wanted to be able to right click a control or terminal and have it look up if it's attached to a case in an Event Structure and display that case.
-
There's goes my first idea for RCF plugin.
-
DISTek Integration, Inc. is a provider of precise electronic systems and product testing systems. As an engineering systems solutions provider, we partner with our clients to design smarter, safer and more sophisticated machines and electronics operations.
Due to growth, we have an immediate opening for a Test Engineer to join our team of engineers in the Cedar Falls/Waterloo community. DISTek offers competitive salaries, a flexible work schedule and a full range of benefits. Please join us for an exciting and challenging career with the potential that only a growing high technology company can offer. Below is a description of the Test Engineer position.
The candidate must be willing to relocate to the Waterloo/Cedar Falls, Iowa area.
Test Engineer
The Test Engineer is responsible for the design, development, deployment and support of test systems for electronic products. Position includes high-level functions such as test planning, detailed design and development of test software. The Test Engineers required to acquire, document, review, and interpret customer requirements and specifications. From these requirements, the engineer will design and develop the solution and produce plans and procedures required by the customer.
Primary functions of the Test Engineer include:
Producing test software using National Instruments’ LabVIEW, TestStand, LabWindows/CVI or other software to meet customer requirements
• Interfacing with customers to help develop requirements
• Developing test plans, schedules, and other project documentation
• Coordinating field tests, lab tests, supplier tests and government certification tests as required
• Using schematics and device data sheets to understand equipment functionality and develop necessary test criteria
• When appropriate, conducting required testing, analysis of data and writing reports
• Integrating and commissioning of systems at customer facilities
Key technical skills and qualifications needed are:
• 4 year degree in an applicable Engineering or Science program or a Technical degree plus equivalent work experience
• Minimum 3 years experience within an electronic product test development and production environment using automated test equipment
• Proficient in National Instruments LabVIEW-based programming, National Instruments TestStand programming; NI Certified LabVIEW Developer or Architect preferred
• Strong PC skills
Other desired skills are:
• Familiarity with C/C++ programming
• Experience with data management, data acquisition, device control and instrument communication
• Willingness to achieve certification through National Instruments program
• Good written and oral communication skills
• Ability to work within a team (internal/customer) environment
• Knowledge in software test tools and communication protocols
• Experience working with embedded systems running real-time operating systems
• Minimal travel may be required within the US and abroad
• Microsoft Visio and Microsoft Project
To apply please send your resume, cover letter and salary requirements to: hr@distek.com or Mail them to the address listed below, Attention HR.
DISTek Integration Inc.
6612 Chancellor Dr. Ste. 600
Cedar Falls, Ia. 50613
-
-
-
-
I can beat that one.
This is actually my Beetle and this is actually my plate. (use Norms "time to comprehension" scale)
It was that or "Y2K BUG" because it is a 2000.
Ed
-
As Michael mentioned, I had some travel troubles both ways. (I flew American Airlines) Though I managed not to get stuck overnight anywhere.
Flying from Cedar Rapids to Chicago was no problem. Had about an hour and a half layover in Chicago. Flight is suppose to leave for Austin at like 1:30. It's 1:25 and we're still not on the plane even though the boarding time says 1:00. It's not looking good. They finally let us start boarding around 1:45. Not too bad. I've never gotten out of Chicago on time and this was actually fairly good for them.
So everybody is on plane just sitting and waiting, sitting and waiting, sitting and waiting. Finally, after about 30 minutes the pilot and a mechanic (I'm guessing) came walking down the aisle looking, pointing and feeling at the ceiling and the area above the overhead luggage compartments. They walk up and down for about 5 minutes then they disappear onto the jet way. Another 5 minutes and they're back doing the same thing. This isn't looking good at all.
They disappear again and another 5 minutes go by. We now hear the pilot over the intercom. It went something like, "Good afternoon ladies and gentlemen. This is your pilot Captain Over.
I'm sure you noticed us in the aisle and some of you may have noticed the slight burning smell ( I hadn't) in the cabin. We seem to be having some electrical problems that we can't quickly identify, plus there's a liquid dripping onto some of the seats and into the aisle. At this point, I'm not comfortable flying this plane to Austin. And if I'm not going, unfortunately, you're not going either. We're going to need everybody to grab everything you brought on board with you and go back into the terminal. We'll provide more information as soon as we have some. Sorry for the delay."A noticeable groan was heard from the passengers. I was in the far back of the plane so I was one of the last to get going. As soon as I stood up, I knew he made the right decision. You know that smell when you let the magic smoke out of some electronic doodad? Mix that with wire insulation that's smoldering and that's what it smelled like. Then, as I'm making my way up the aisle, something drips from the ceiling right in front in of me. As I walk by the captain I just smile and say, "Good decision". :thumbup:
So we're back in the terminal waiting in the gate area. They announce that our plane is out of commission and they are looking for another one. They finally announce a 3:30 boarding time at a different gate. Got another hour to kill.
So we get on the new plane. Captain Over gets on the intercom again and says, "Thanks for your patience and understanding. A preliminary look at the problem on the other plane revealed a fairly serious electrical problem. So we did make the right choice. We all should thank our flight attendants for first reporting the problem."
So now we’re flying home. Austin to St. Louis to Cedar Rapids. What can go wrong? Not going through Chicago.
Austin to St. Louis was no problem. We’re suppose to leave St. Louis at 7:30. It’s like 7:45 and we’re not on the plane and the board still says we’re “on time”. Not again.
We finally find out that they don’t know where the flight attendant is. Around 8:30, they say now they think there may have been a scheduling error and he might be on a different flight. But they do say they have now called in a replacement, but it will take about an hour for her to get there.
She shows up, we board around 9:45 and finally get to Cedar Rapids around 10:30. Only about 2 and half hours late. The captain then tells us that they just don’t know where the scheduled attendant is. He’s not on any flight and they can’t reach him by phone.
So, between the two flights, the flight attendants avoided a potentially serious problem on one flight and caused a lengthy delay on the other. Although his replacement saved the flight by actually getting out bed and taking the flight so we could get home. :worship:
And I have other travel stories from I worked at Rockwell Collins and traveled internationally. Like the time our 747 was frozen to the tarmac in Minneapolis and the 'tug' couldn't push us back from the gate. Or when we got stuck in Tokyo overnight because our DC-10 was too loud to take off after 10 PM. Or when I got on the wrong local flight in Taiwan and ended up in the wrong city where no one spoke English. Or the drunk that taken away in cuffs because he was upset about our flight being late due to the blizzard. (Minnapolis again)
-
I just turned my Twitter account back on. :gathering:
-
I'll be there Saturday through Friday.
I'm taking the new LVOOP class sunday and Monday and I'm heading down to San Antonio Firday to meet with the guys from Drivven.
We're staying at the Hilton and I at least will be at The Ginger Man Sunday evening.
Ed
-
mmmmmmm
BBQ within stumbling distance of 6th street this year. Can't pass that up.
-
The "Convert Panel To Screen Coordinates" method does not work on VIs in Run mode.
If you use this method on a VI in Run mode, you receive the follow error.
"Error 1073 occurred at Invoke Node in CvtPanelToScreenCoords.viPossible reason(s):LabVIEW: This property is writable only when the VI is in edit mode, or this method is available only when the VI is in edit mode.Method Name: Convert Panel To Screen Coordinates"
The help file indicates this is the correct behavior stating that it is not settable when the VI in running. I brought this to NIs attention and they agree that the method is not very useful on a VI in Edit mode, so they filed it as a bug (CAR # 105629).
-
QUOTE (Justin Goeres @ Apr 26 2008, 09:50 AM)
So my hometown (Cedar Falls, IA) and surrounding areas are flooding. That happens every so often, and apparently some areas are getting hit pretty hard. Too bad
. I hope the DISTek people are all OK 
.
I wonder if there's any NI hardware in the system?
Our office is OK. It's not near the river.
Some of our people do have water in the basement or have had a flash flood run by their house.
My dad lives right on the river and was expecting 2-4 feet of water in his garage. His house is on top of the garage, so he didn't get anything in the house. We just empty the garage when this happens. It's built for it. I'll see if he's got any pictures.
Ed
-
Has anybody tried creating a tool that will look at a project and automatically compile all FPGA VI's it finds?
I've got the easy part done. I can get a reference and path to all FPGA VI's in a project, but have not yet found a way to trigger the compile process. I was hoping there would be a Method, but I don't see one.
I'm about to start digging for the Compile VI's to see if I can pass the VI's path or reference.
I'm doing this 8.2.1.
Ed
-
DISTek Integration, Inc. is a provider of precise electronic systems and product testing needs. As an engineering system solutions provider, we partner with our clients to design smarter, safer, and more sophisticated machine and electronics operations.
Due to growth, we have an immediate opening for a test engineer in our Cedar Falls Development Center. DISTek offers competitive salaries, a flexible work schedule, and a full range of benefits. Please join us for an exciting and challenging career with the potential that only a growing high technology company can offer. Below is a description of the Test Engineer.
Test Engineer
The Test Engineer is responsible for the design, development, deployment and support of test systems for electronic products. Position includes high-level functions such as test planning, detailed design and development of test software. The Test Engineer is required to review and interpret customer requirements and specifications and then develop and produce plans and procedures required by the customer.
Primary functions of the Test Engineer include:
-
Producing test software using National Instruments' LabVIEW, TestStand, LabWindows/CVI or other software to meet customer requirements
-
Interfacing with customers to help develop requirements
-
Responsibility for developing test plans and schedules
-
Coordinating field tests, lab tests, supplier tests and government certification tests as required
-
Using schematics and device data sheets to understand equipment functionality and develop necessary test criteria
-
When appropriate, conducting required testing, analysis of data and writing reports
Key technical skills and qualifications needed are:
-
4 year degree in an applicable Engineering or Science program or a Technical degree plus equivalent work experience
-
Minimum 3 years experience within an electronic product test development and production environment
-
Proficient in National Instruments LabVIEW-based programming, National Instruments TestStand programming, and automated test equipment; NI Certified LabVIEW Developer preferred
-
Strong PC skills
Other desired skills are:
-
Familiarity with C/C++ programming
-
Experience with data management, data acquisition, device control and instrument communication
-
Willingness to achieve certification through National Instruments program
-
Good written and oral communication skills
-
Ability to work within a team (internal/customer) environment
-
Knowledge in software test tools and communication protocols
-
Experience working with embedded systems running real-time operating systems
-
Minimal travel may be required within the US and abroad
To apply please send your resume, cover letter and salary requirements to: hr@distek.com or Visit us online at: www.distek.com and apply.
-
Producing test software using National Instruments' LabVIEW, TestStand, LabWindows/CVI or other software to meet customer requirements
-
QUOTE(rolfk @ Apr 12 2007, 05:01 AM)
Well, you can't embed a string in a cluster and just pass that to the DLL. A LabVIEW string is something very different than what a C DLL would expect. Also the prototype clearly shows the string as a fixed size entity which means it is inlined in the structure and not even a C string pointer (which actually makes it easier for us to call it from LabVIEW if done right). So what you want to do is passing a flat buffer of bytes to the function with the needed size.Something like what is shown in the attachment.
One afterthought. Your size numbers you mention indicate that the structure only uses 97 bytes for the structure. From what I can see in the header file the only thing I'm not sure about is the BOOLEAN datatype. The usual Windows type is BOOL which is a 32bit integer but BOOLEAN seems to be defined as a BYTE type. So obviously your structure would be only 97 bytes long and Softing seems not to use padding in their API which makes the buffer always a multiple of this value.
This would mean you will have to adjust the attached VI slightly to get the right data from the buffer. Basically changing the 20 constant to 17 should already work although you may have to make sure that the embeed boolean gets interpreted right too.
Rolf Kalbermatter
Thanks Rolf, that did the trick. My lack of C knowledge is showing.
I did manage to figure out that the 20 needed to be 17. I noticed the returned size was off as well and thought that was causing the original problem. I cna't figure out what they are doing with the boolean either, but it doesn't seem right.
Ed
-
QUOTE(chrisdavis @ Apr 9 2007, 08:10 PM)
I've used many dlls in LabView 7 and have never had to set a VI that had a DLL to reentrant. If you can find the knowledge base article(s) with this information please post them.In my experience, it is usually a problem with the setup of the DLL being called, or in the DLL itself. If you can get the function to work in a simple C program the way you want to call it from your DLL you are probably in business. Although I have found that DLLs that allocate thier own memory (as yours seems to do) usually require a seperate wrapper DLL that you have to write to make them function reliably in LabView.
YMMV
BTW, I did try and open your code, but since it was saved in 8.2.1 I couldn't open the actual VI. Since 8.2.1 was released less than a week ago, you might consider backsaving to something that is a little more universal, so those who haven't even gotten thier 8.2.1 CDs can actually view the code in LabView. Just a suggestion...
Here's the VI saved back to 8.0. Please note that this version is slightly different than the 8.2 version as the "Data Formats" for the "Adapt to Type" are different between 8.0 and 8.2.
8.2.1 VI will be able to be opened in 8.2 without backsaving. This has always been true for maintenance releases. (at least back to 6.0.2)
I've never had to set a VI as Reentrant either to get a dll call to work. I've got most of the other functions in this dll working and none of their VIs are set to be Reentrant.
Ed
-
I'm having problems getting a particular function ina dll to work. I'll try and provide all the needed documents and files hoping some one can point me in the right direction.
Included in the attachment is the .dll, the VI I'm working on for this function, the documentation for the function, the header file for the dll and a sample C source file that uses this function.
The problem I'm having is the function appears to return the data, but when it attempts to write the data to the indicator, LabVIEW crashes. The function is suppose to be run twice. On the first run you're suppose to have the "ProvidedBufferSze" parameter set to 0 and the "Buffer" = Null. After the run, "NeededBufferSize" will contain the needed bffer size that can be used on "ProvidedBufferSze" on the next call.
The size of the structure containing the data is suppose to be 100 bytes according to the documentation. On the first run of the function, "ProvidedBufferSze" returns 194 with a two channel device in the PC. It seems to me this should be 200. On the second run with either 194 or 200 on "ProvidedBufferSze", the function (running with execution highlighting on), I can see the "Buffer" return a 2 element array. When this array is written to the indicator (or a probe), LabVIEW crashes and I get the Windows "Send Error Report" dialog.
Mainly I just want to verify that I have the CLN setup correctly and my logic in the VI seems correct. After this, I'll probably end up calling the manufacturer to see what they have to say.
Thanks
Ed
-
Here you'll see a minor Application Builder display bug in LabVIEW 8.20
http://forums.ni.com/ni/board/message?boar...=224548#M224548
Ed
-
Has anybody tried to open this tool in either 8.0 or 8.2?
I get an "Fatal Internal Error" and LabVIEW shuts down.
Ed
-
The quick and easy answer to your original question is... there is no quick and easy answer
If you're already familiar and comfortable using C and don't really know LabVIEW that well, you'd be better off sticking with C. LabVIEW Embedded does make it easier for the non-embedded programmer to program an embedded target. But why go through another learning curve if you don't have to. And the $10,995 price is a huge investment if this is just a single small project.
On the other hand, if you struggle with C and know LabVIEW pretty good, then a switch to LV E might not be a bad choice. Development time can be significantly less and you have all the nice LV debugging tools. There are some differences between LV and LV E as far as application optimization, memory usages, array and constant handling and a few other things that can bite you if you don
Alliance Member seeking Test Engineer
in Job Listings
Posted
DISTek Integration, Inc. is a provider of precise electronic systems and product testing systems. As an engineering systems solutions provider, we partner with our clients to design smarter, safer and more sophisticated machines and electronics operations.
Due to growth, we have an immediate opening for a Test Engineer to join our team of engineers in the Cedar Falls/Waterloo community. DISTek offers competitive salaries, a flexible work schedule and a full range of benefits. Please join us for an exciting and challenging career with the potential that only a growing high technology company can offer. Below is a description of the Test Engineer position.
The candidate must be willing to relocate to the Waterloo/Cedar Falls, Iowa area.
Test Engineer
The Test Engineer is responsible for the design, development, deployment and support of test systems for electronic products. Position includes high-level functions such as test planning, detailed design and development of test software. The Test Engineers required to acquire, document, review, and interpret customer requirements and specifications. From these requirements, the engineer will design and develop the solution and produce plans and procedures required by the customer.
Primary functions of the Test Engineer include:
Producing test software using National Instruments’ LabVIEW, TestStand, LabWindows/CVI or other software to meet customer requirements
• Interfacing with customers to help develop requirements
• Developing test plans, schedules, and other project documentation
• Coordinating field tests, lab tests, supplier tests and government certification tests as required
• Using schematics and device data sheets to understand equipment functionality and develop necessary test criteria
• When appropriate, conducting required testing, analysis of data and writing reports
• Integrating and commissioning of systems at customer facilities
Key technical skills and qualifications needed are:
• 4 year degree in an applicable Engineering or Science program or a Technical degree plus equivalent work experience
• Minimum 3 years experience within an electronic product test development and production environment using automated test equipment
• Proficient in National Instruments LabVIEW-based programming, National Instruments TestStand programming; NI Certified LabVIEW Developer or Architect preferred
• Strong PC skills
Other desired skills are:
• Familiarity with C/C++ programming
• Experience with data management, data acquisition, device control and instrument communication
• Willingness to achieve certification through National Instruments program
• Good written and oral communication skills
• Ability to work within a team (internal/customer) environment
• Knowledge in software test tools and communication protocols
• Experience working with embedded systems running real-time operating systems
• Minimal travel may be required within the US and abroad
• Microsoft Visio and Microsoft Project
To apply please send your resume, cover letter and salary requirements to hr@distek.com or Mail them to the address listed below, Attention HR.
DISTek Integration Inc.
6612 Chancellor Dr. Ste. 600
Cedar Falls, Ia. 50613