Jump to content

Dean Mills

Members
  • Posts

    28
  • Joined

  • Last visited

Profile Information

  • Gender
    Male

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2012
  • Since
    1994

Recent Profile Visitors

2,280 profile views

Dean Mills's Achievements

Newbie

Newbie (1/14)

  • Week One Done
  • One Month Later
  • One Year In Rare

Recent Badges

0

Reputation

  1. The greenish tint could be caused by whatever software you are using is not doing the bayer color decode properly. A Google search for bayer encoding will return many results on what bayer encoding is and how to decode it. Usually the Basler software will work properly but other software may need to be told its Bayer encoding.
  2. Just passed the CLD

  3. Hi all, I can say that I have come across a behavior like this. It is similar to having a case structure called by a string and someplace somewhere you mistype the case you want to go to or you don't use case insensitive match and mix up the case. If you haven't wired up a catch all that tells you you have misspelled you need to debug to find it. This could be quick if you an experienced LabVIEW programmer but what about a new user? Having worked with a dozens of other programmers that haven't created their own programming style yet and somewhat hide code it is easy to have this case come up. Mostly in my previous code there is a single case to handle communications between processes and we tried to fit other dynamic events in there when necessary to avoid the weirdness and control how to search for where events are called from. There needs to be better control over the events, like what exists in all Semaphores. Perhaps it is something as simple as an error case, which is for unhandled events. A default case that if the event fires it goes there if there is no event case to handle it. The case structure has a default, which is a catch all, why doesn't the event structure? Dean
  4. has not set their status

  5. Hi, A couple of things. What is the timeout on the RT FIFO's? If it is not 0 you need to make it 0 and handle the case when there is no data. They can use most of the CPU waiting. I try to avoid using the RT FIFO's unless they are absolutely necessary and tend to just use Queues. What is the timeout on the TCP read and write functions? They need to be appropriate for the application. This is usually a trial and error but I generally start with about 1 second. In the past while using TCP on cRIO's I have experienced lots of lost data. I had to implement a scheme of attaching a unique id to the data, send it to the PC and wait for a confirmation that the data was received before I sent the next chunk. In my experimentation TCP functions should not be in timed loops, TCP functions should reside in their subvi without any time critical loops. I also only send data about every 250ms. For me that creates about 8k of data per send. Dean
  6. Neil I have just finished reading this thread...Lots to read. I have created a few test executives the past, including 1 with true parallelism and a scripting language to control it. The best advice I can give, based on your current information, is don't try to add any hooks in now. Generally the reason for adding hooks is to make it easier to upgrade in the future. At Meikle we have legacy code that is over 9 years old that hasn't been touched in that amount of time. The last major upgrade to the test executive was about 7 years ago when I went with a dynamic parallel version. Current updates are more hacks than actual designed code. I wrote the original with what I thought were hooks in it to handle multiple parallel processes. I was somewhat off the mark. I ended up keeping 1 piece which was the actual VI that called all of my steps. The rest I rewrote from the ground up with some software that allowed me to launch, manage the number of parallel engines and test them. The result was 1 user interface with multiple low level engines. I now fondly think of that first version as a pre-proof of principle. All of engines and steps are based off of the exact same queued state machine template, which now uses event structures, but dynamic events vs queues is a whole other nasty discussion. I cannot stress how important it is to use the exact same template, cause many years down the road you will look at the code and go "what was I thinking, why are they so different." The current architecture is a launcher that will launch the engines and close all the dynamic references, this also loads all the dynamic reentrant steps. Another VI that manages what engine is running what sequence (this is called dynamically from several other VI's with information about what script to run), one very convoluted VI that retains feedback about how each step of each script ran or is currently running, yet another VI which displays the timing information, one other VI that allows for a running from a user interface and the last creates the script. The actual TE VI includes a UI which allows for breakpoints, single stepping and running for debug. Within the language we have if else, rendezvous, semaphores and looping statements. We use these to control parallel processes as a TE step exists that can launch another TE either inline or parallel. As for Teststand, I remember looking and playing with version 1. It was really suitable for what we were trying to accomplish. The people who were concerned with the cost of deploying our software thought the teststand license fee was better suited to stay at Meikle then send to NI. Besides it was an extremely fun and satisfying challenge to create a TE. Teststand has come a long way but isn't suited to the Meikle business model and industry we reside it. Currently we are moving completely away from this TE format. We have created very accomplished Ladder Logic editor and engine that runs our stuff. It is very fast and easy to use. The problems and issues we have with our test executive is slowly going away as we are stopping using it. This is mostly based on the requirement we have of controlling an assembly machine or test machine with cylinders, motors, e-stops, MCR's, PLC communcation etc. As a scan of all IO and a sequencer written in Ladder is much easy to integrate. From being able to upgrade code in the future I tend to look and design software with the philosophy that any VI which is a UI screen, any dynamic called engine, basically any independant entity should be able to be rewritten and plug back into the code very easily, without breaking the existing code. Based on that philosophy, my advice would be to have 1 user interface, 1 main program, 1 script manager that would sequence and control any test script being executed and 1 engine to run the script. Currently this wouldn't have the parallel capability but in the future you rebuild the script manager and the test script engine from the ground up to handle the parallel testing. Good luck, Dean
  7. In case no one has looked inside the semaphore VIs. The semaphore is just a wrapper for a queue. I haven't looked inside it for many years (LV6 likely) but the not a refnum got me thinking, what is it inside. The rendezvous VI's are also just a wrapper for a queue. Dean
  8. QUOTE (pallen @ Aug 20 2008, 09:27 AM) If you have a choice to upgrade you should upgrade. The upgrade on our software package was quite painless except for some issues with the OOP version of the report generation toolkit and a couple of other VI's that NI and Meikle has that are the same name. Building exes with this situation is interesting. But all in all for about 4500 VI's and type def's it only took about 5 hours to load and fix the broken code. We are still testing it but there doesn't seem to be any major issues or bugs. We have upgraded a couple of customers in the field already with only one incident which took about 1 hour to fix. However, we maintain a copy of the code in each version of LabVIEW back about 4 LabVIEW versions with SVN. Older than these projects are generally orphans that contain information on which versions of LabVIEW they werer built in. We try to maintain backwards compatibility with all version but there is always something that gets missed after a projects hits the 3-4 year mark in age. Since LabVIEW 8.2 came out I have invested in a usb drive and VMWare. I maintain a fairly clean copy of Windows and when a new version of LabVIEW comes out I create a new VMWare copy of the base Windows and install LabVIEW and all the other stuff. I generally find 10Gigs to be a big enough partition. When I need to support or upgrade an older project I open VMWare corresponding to the version of LabVIEW and use it. Right now I am compiling a bug fix for a LabVIEW 8.2.1 project. Overall I am quite pleased with the ease of this upgrade compared to others. The 4 DVD's we received and the new installer screen at the beginning of install is a tremendous leap forward. Dean
  9. Go here for information http://zone.ni.com/reference/en-XX/help/37...evious_version/ Dean
  10. Hi My recommendation would be to look in the NI example folder. There are a few examples on doing Basic IO there with a cRIO. You need to look under Toolkits and Modules=>FPGA=>CompanctRIO=>Basic IO=>Analog Input - cRIO.lvproj On my computer it is here C:\Program Files\National Instruments\LabVIEW 8.2\examples\CompactRIO\Basic IO\Analog Input\Analog Input - cRIO.lvproj Replace the LabVIEW 8.2 with your version. This is the best way to learn. This example also contains code to allow for converting the binary value to voltage. Binary 0 does not equal 0 volts. Dean
  11. I often wonder how people find the time to spend so much time on LAVA, Info-LabVIEW, Developer Zone. I can usually find the time to read about a quarter of all the feeds that come in so I relegated to a lurker. I have some time right now as I am waiting for the machine I am working on to be put back together and since Mike asked so nice for lurkers to say hi. So just to drive this in a different direction and as a question I have wanted to but never have, how do some of you find the time to read and discuss so many questions? Are the rest of us just poor at time management or work too much. I am working on a very bad project right now so I am averaging 80 hours a week but usually work 55 or so. Dean
  12. I am trying to remember, but I think you can turn off the reentrancy, turn on debuging, open the diagram and fake it. I have very vague memories of debugging a callback VI like this. Not using a breakpoint but just opening it, its diagram and using probes. Dean
  13. Hi Mike, I don't think there is a way to debug this? You can try changing palettes perhaps there is something in there? When you upgraded to 8.2.1 did you reinstall the toolkits. I remember reading something somewhere warning about that. What I did to speed it up was reinstall the OS and run only 1 LabVIEW version. I realize this is likely not an option but it will make a huge difference. My load time after reboot on LV8.2 went from 2+ minutes to 30 seconds after I reinstalled XP. Relaunching LabVIEW always starts faster as long as you don't run other programs. I also removed the LV8.0 install. All other software was the same without the left over crap of 1 year of upgrades and new versions. One other slow down I had was caused by the virus scanner getting reset and started scanning .vi's again but that was only noticeable when loading 2000+ VI's. I use vmware to support older versions but if you can't allocate 1 gig of ram to the vmware portion it runs really slow with LabVIEW and you have a large project like Meikle does. Dean
  14. Hi all, Meikle Automation is looking for a LabVIEW Programmer. An overview of the MASS software can be found at: http://www.meikleautomation.com/products/mass.php This position is in our facility in Kitchener Ontario Canada. MAJOR DUTIES: To work as a team member in providing Meikle Automation Software Suite-based solutions which meet the needs of our customers by writing, testing, deploying, and supporting PC-based software code, written in LabVIEW, from National Instruments To work with electrical and mechanical team members to fully integrate the Meikle Automation Software Suite solution. This includes interfacing with toolmakers, electricians, mechanical designers and electrical designers from any group to ensure compatibility of operations. SPECIFIC RESPONSIBILITIES INCLUDE BUT NOT LIMITED TO: Programming of MASS Code · Design and create code using LabVIEW™ from National Instruments. · Testing, validation and documentation of code personally created, and created by other members of the MASS Development Team. Solution Deployment · To support the deployment of projects incorporating the MASS. · Be on-site for the set-up, debug, and sign-off stages of projects using the MASS · To provide telephone, online and on-site support for projects using the MASS Testing · To provide testing support to the MASS Development Team, supplementary to the project-based minor steps and procedures by assisting in the development and execution of test plans. Apply at: jobs@meikleautomation.com Thanks Dean Mills
  15. Hi all, A collegue of my found this bug. There is a bug in LabVIEW 7.1 where if you have a for loop, a constant outside the loop and do simple math, such as subtract on a constant that resides inside the for loop it treats the top terminal as 0 . See attached. Directions Place a for loop on the diagram, wire 1 to the count terminal Place a constant on the diagram outside the for loop, use any postive number. Place a constant inside the for loop, use any positive number. Subtract them with the constant outside the for loop wired to the top terminal. Wire the result of the subtract to the output of the for loop, disable indexing. Wire the top terminal to the output of the for loop, disable indexing. Probe the output of the subtract. Run VI I have tried add, multiple and divide. Same bad results This has been submitted to NI as a bug report. DeanDownload File:post-5-1097694319.vi
×
×
  • Create New...

Important Information

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