Mark Yedinak

QUOTE (manojba @ Apr 12 2009, 11:51 PM) Would you mind giving us some details about how you handled it? After all, the intent of LAVA is to share good ideas. If you found a good way of doing this I am sure others would appreciate hearing about your solution.

Software Test Engineer V Join Zebra and EARN YOUR STRIPES!! Who is Zebra? Zebra Technologies Corporation helps companies identify, track and manage assets, transactions and people with on-demand specialty digital printing and automatic identification solutions. In more than 100 countries around the world, more than 90 percent of Fortune 500 companies use innovative and reliable Zebra printers, supplies, RFID products and software to increase productivity, improve quality, lower costs, and deliver better customer service. To learn more about our broad range of applications visit our homepage at www.zebra.com. Why join Zebra? Zebra Technologies is a career-defining place to work that can offer you: • A challenging job where you can really make a difference. • A friendly and collaborative work environment. • A dynamic and growing company. If you're interested in this kind of company and ready to earn your stripes, we invite you to explore this opportunity! Tell me more! We currently have an opportunity for an experienced Software Test Engineer in our Specialty Printer Solutions business unit located in Warwick, RI. In this role, you will create, influence, implement, maintain and recommend changes to test strategies, procedures and instructions, test software, and product qualification processes. Promote standard test and automation methodologies for use throughout the company. Identify and recommend test equipment required for product verification and qualification testing. Provide training of Qualification test personnel as required to ensure thorough test coverage. Assist in the testing and evaluation of new and/or modified products to ensure that products contain no unidentified problems when released to manufacturing. This position requires an individual with a passion for developing and implementing test strategies, policies, infrastructures, and functionality for ensuring high quality hardware and software for wired and wireless printer devices. Solid networking test development background, 10+ years experience. Knowledge of wireless technologies such as bluetooth and 802.11b/g are key. The work involves identifying, qualifying, recommending, and implementing 3rd party test tools and hardware as needed to provide a state of the art text infrastructure. Successful candidates are self starters that work well individually, as part of a team, and are driven to make a difference in what we deliver to our customers. Responsibilities: Promote improvements to the product specifications to ensure testable requirements are generated for new products and features. Collaborate with product development teams to promote product functions and features that enable and assist product testing, data collection and test verifications especially with respect to automated testing. Champion improvements in the overall test process that can be used throughout the company to standardize the testing methodology as well as drive towards a standardized infrastructure to support increased test automation. Design and develop automated testing applications, utilities and modules that conform to best practices for software development. Design, develop and improve the collection of test data and results as well as improve the storage and retrieval of parametric data used for testing. Create test strategies, test plans, test procedures or instructions based on the marketing requirements document (MRD), the product requirements document (PRD) or engineering specifications for product qualification. Design and build test fixtures for the evaluation of verification testing or the validation of product qualification testing. Ensure that products being qualified are representative of the latest engineering designs as well as best manufacturing practices. Establish, implement and problem solving techniques on identified anaomalies/bugs and improve the cost of quality of our processes, parts and products. Perform data analysis (using statistical and graphical methods) to ensure only accurate information is presented and summarized to management. Prepare accurate cost and time estimates of proposed test projects. Maintain accurate and reliable records of tested projects (including test plans, data, analysis, engineering communications, and final summary reports). Prepare and distribute final project reports. Contribute ideas, as part of the quality team that will help improve our documentation, processes, and overall performance and reliability of our products. Performs other duties as assigned by management. Qualifications: B.S./M.S. Degree in Computer Science or equivalent experience 10 years experience in Engineering or Quality Assurance test facility with supervisory and mentoring experience Proficiency with computers and experience with scripting languages (Python, Perl, Expect, Tcl), databases, spreadsheets, and word processing programs Proficiency with interfacing computers with laboratory equipment Details-oriented, capable of quantitative technical analysis Effective oral and written communication skills Approximately 15% travel required What can Zebra offer me? We offer competitive salaries and a comprehensive benefits package to include Medical, Dental, Vision and Life insurance, LTD, 401(k) (with immediate company match), Employee Stock Purchase Plan, Tuition Reimbursement, and more. To apply for the position and learn more about our benefits package, please visit our career center at www.zebra.com/career. Note: We will be moving to Lincoln, RI in the next few weeks.

OK, here are a few of my thoughts regarding your application. First, overall you did a good job. There are a few areas though where I think you might get dinged. First, be very, very anal about your wires. Avoid any and all unnecessary bends. You have a few spots where you good straighten out your wires. For instance, the error case in your consumer loop where the Error state ENUM wire is not straight. I would also avoid leaving your block diagrams maximized when you save them. Size them to the appropriate size and leave them that way. I think you will want more documentation inside your code to explain what is happening, especially on constants. Your purchase selection is not very open to extension, you would be better of using a more generally selection so that it can grow easily. As it stands now you will have some major rework if you added additional wash types. I would also remove the unused timeout event case on your event structure. Avoid using property nodes to write values to controls. This one seems to be a big no-no in the exams. Avoid using "Use default if unwired" for your case structures. Make sure you customize all icons, including your main vi. A few things that I don't think they would comment on or ding you for but I thought I would mention anyway. Use good names for your controls and cluster elements. Main_states doesn't really describe what that element is. I like names to be very clear about the element and IMO I believe Current State better reflects what the element is. I am also extremely anal about my diagrams and go as far as aligned objects between different cases in a case structure. I realize this is extremely picky but it does make the code appear more polished. Anyway, those are my basic thoughts. Good luck on you exam when you take it.

QUOTE (PaulG. @ Apr 10 2009, 02:43 PM) Yes, cost is one negative of TestStand. Unlike LabVIEW you can't freely distribute your executable. TestStand requires a deployment license. In terms of the cost for the development system that is fairly easily recouped by the productivity increase. As mentioned earlier TestStand does have a fairly steep learning curve but once you understand how it works it is fairly easy to work with.

QUOTE (jcarmody @ Apr 10 2009, 02:09 PM) TestStand is not a text based scripting tool. Where are you getting that from?

It would be nice if LabVIEW provided a generic sort algorithm that the developer could plug a custom comparison VI into it. C++ has this capability so they have a very efficient sort algorithm and all you need to provide is a view of the data structure and a comparison function. This way you can efficiently sort an array of any data type. This would be a very nice addition to LabVIEW. Imagine being able to sort arrays of clusters easily with the additional ability to be able to sort on more than just the first element.

Yes, TestStand could work for your solution and it is capable of testing multiple UUTs at one time. It can even share resources between the parallel tests and automatically switch the resource to a different UUT. In addition, it could run other tests that are not dependent on the shared resource at the same time. TestStand has different models for its testing and the default model is designed to test a single UUT at a time and repeat this over multiple UUTs sequentially. The three common models are sequential (the default example stuff), parallel and batch. In the past I have wondered myself sometimes if it is better to do a LabVIEW only system of use TestStand and LabVIEW. We are currently in the process of building a fairly large test system and though we are finding some quirks with using TestStand we are happy we chose to use it. It implements many things that we don't have to worry about so we can concentrate on writing the tests and not the test executive. If I were you I would give it a serious look. You may want to contact your NI rep so that they could help you see TestStand's full potential.

I just tried to take a look at your code but I currently don't have 8.6 installed. If you want to save it to 8.5 I can take a look.

QUOTE (Ic3Knight @ Apr 10 2009, 10:26 AM) You could read the data in chunks and then add that to a buffer of data to be processed in a separate task. This task could then parse the data using regular expressions to pick off the messages from the beginning of the buffer. Once it gets a complete message it could either process it immediately or pass that off to your message handler. It can continually do this as long as data is available.

QUOTE (335x @ Apr 9 2009, 11:21 PM) Yes it is possible and it is generally recommended that your user interface allows there types of operations. This is why the producer/consumer design pattern along with a queued state machine in the consumer is recommended for the control of your user interface. You can explicitly allow the user to reinitialize things to a default or desired configuration. You usually don't need to provide this type of functionality for low level subVIs. However it is definitely a good thing to provide at the higher levels of the application such as the user interface.

See posts #2 and #3 earlier in this thread. Your question has already been answered.

QUOTE (jdunham @ Apr 8 2009, 01:27 PM) The reason I would want to convert the data is when I would define a generic message construct for passing data between processes. The generic subVis would use a cluster for the message type which consists of an U16 and a variant. The subVIs used to actually pass the messages have no need to know anything about the message data or its content. The only part of the application that needs to know what the message type means is the actual source and destination of the message. However it is useful for the message type to be defined as a typedefed enum at the source and destination of the message. So the message type would be treated as an enum at the source and destination but would be treated as a simple U16 within the actual message. I suppose I could define the generic message type as a variant. This would result in cluster for the message data to be two variants.

QUOTE (normandinf @ Apr 8 2009, 10:37 AM) No, I will have to give this a try. QUOTE (neBulus @ Apr 8 2009, 10:52 AM) As long as the input is U16 is works fine for me. What problem did you observe? Ben If you typecast an enum to a u16 and wire it to a case structure you don't get the string values of teh enum so the cases are simply 1,2,3, etc. Therefore you lose the readability. Also when I have typecast a U16 to an enum it always seems to retunr the value of teh first enum rather than the actual value input.

I haven't used this particular example of a queued message handler but have used them extensively in my applications. Liek Paul, I prefer to use a typedefed enum to define my states. I do realize that strings are very flexible but using strings can cause a mess overtime because if a state name of message type is changed all code that used that must be updated. When using a typedefed enum everything using it will pick up the change. Of cousrse this does mean that you can have a single re-usable library for your message handler but rather use a template that is customized for each application. For me the additional work required when using the template is worth the effort. Now if only LabVIEW allowed you to truly typecast an unsigned 16-bit integer to a enum then everything would be great. However I have not found typecasting of integers to enums to work correctly.

What do you mean by Windows can't open it? Do you mean that if you double click on it it doesn't start LabVIEW? Windows by itself has no clue what to do with a .llb file. It needs to know that it is associated with LabVIEW and pass the file off to LabVIEW for handling. Can you open the .llb file directly from LabVIEW?

QUOTE (crossrulz @ Apr 7 2009, 02:23 PM) I agree completely with not using front panel items for temporary data that the user doesn't need to see. I try to keep all such data in shift registers, functional globals or LVOOP objects. However, when dealing with a front panel control exposed to the user it seems that you have to use a local variable or property node. There simply is no way to read from an indicator or write to a control without them. Lately I have even been isolating the UI much further and using queues to pass data between the processing tasks and the UI task. I just seem to remember attending a seminar put on by NI back in the mid to late 90's where they were receommending property nodes over local variables. So the comment earlier in the thread surprised me.

QUOTE (shoneill @ Apr 7 2009, 11:59 AM) When did this change? I seem to remember from way back when that property nodes were more efficient and recommended as the preferred method over local variables. I seem to recall NI recommending this at one point. Granted, I it was many years ago but I have generally followed this advice. Should I switch to local variables now instead (that is when I do use them)?

You can programatically write to a control using a property node. If you right-click on the terminal of a control in your block diagram you can create a property node. With this property node you can write a value to the control. You can also change many other attributes of the control as well. Do be careful to avoid using property nodes all over the place in place of data flow. If you use them very liberally you can end up with race conditions in your code.

Just to chime in I can understand the curiosity of someone who is learning and wanting to know how things work. However it is important to stress that if one makes a habit of this and uses it frequently it could hurt in the long run. Many businesses today are very concerned with maintaining a legal operation. It only takes one disgruntled employee to report a business which can result in an investigation of the company and possibly some very large fines. The last thing you want to do for your career is be the person who put a company into this kind of a position.

Are you using a single queue to communicate with all of your spawned tasks? If so, I would recommend that you use a separate queue to send commands to each subtask and then a single queue which all subtasks use to send information back to the main controller. If you do this you will eliminate the need to poll your queues since any message received will be for that task. Using this approach will mean that everything will be event driven and you will not require polling. When a task waits on a queue nothing happens until a message gets posted. If you need to communicate directly between two tasks you can have a message that the subtasks use to request the queue name for the desired task and your main application could then return this information to the subtask. Also, queued state machines are very powerful and we use them quite extensively in all of our applications. They are well worth your time to learn.

QUOTE (shoneill @ Apr 6 2009, 01:37 PM) It seems like it would be possible however I will confess to having very little knowledge of VI scripting. I have never really played around with it.

I would recommend reading up on the producer/consumer design pattern. Use the event structure to capture your UI events and process them quickly. Within the event structure you can notify the task or tasks that are processing the requests. You could use a notifier or a queue for sending the messages. I think that your last design using the four parallel loops may run into some problems. I assume that you don't want to execute your test at the same time that you are calibrating your system. This can happen in your last design since the tasks are truly independent of each other.

QUOTE (Yair @ Apr 5 2009, 01:17 PM) I would agree that it shouldn't be considered evil. However if experience has shown that it is not optimal and open to abuse why not use the other methods which reduce the problems associated with the "abusive" tool. With respect to the stacked sequence structure I would still argue that a state machine would be preferred since it is easily changed if the need arises. After twenty plus years of software development there is one thing I have learned for sure and that it that virtually everything is subject to change at some point regardless of how much we believe it won't. I would rather prepare for the possibility of change rather than write that something that is rigid and very difficult to change.

QUOTE (Lorenzo @ Apr 6 2009, 09:08 AM) Yes, starting your MIB walk at 1.3.6.1.4.1.1356.1.1 will get you the elements under the dcIndent branch. If you also set the END to the same OID than your MIB walk will only return 1 item. The way a MIB walk works is that you use the SNMP GET-NEXT PDU to request the element immediately folllowing the OID given. If you want to walk all of the elements in the upsman MIB then set your start value to 1.3.6.1.4.1.1356.1 and leave the END unset. If the agent is working correctly you should see all of the elements the agent currently contains. An agent that is working correctly will return a nosuchname error for the GET-NEXT of the last item. The GET-NEXT walks the MIB in lexigraphical order. If you would like to walk only the dcIdent branch then set the start OID to 1.3.6.1.4.1.1356.1.1 and the end OID to 1.3.6.1.4.1.1356.1.2.

QUOTE (flarn2006 @ Apr 3 2009, 04:07 PM) My guess is that this feature was not added until classes were added to LabVIEW. Depending on how their internal code was it probably wasn't an easy task to add this capability to other things such as typedefs and clusters. Also, I don't think they would want to allow the user to change the wire type for primitive data types since this would be too confusing. It is good to know that a thin blue wire is an integer and a thin pink wire is a string. If they allowed customization for all data types someone could really confuse the readers of their code by changing the wire types for the primitive data types.