Workflows and algorithms in applications often need proofing and fine tuning, but it can be difficult to do this before you have most of you application ready. We have good experience making software applications to investigate isolated components independently. This way you can test timing and interaction in parallel with your main application development.
A concrete example is a bagage handling application - a couple of miles of steel track and electronics. The customer needed to test out different algorithms for dropping off materials into chutes, so we made a software application that enabled them to try out different timing schemes and tilt angles. The result was early factual knowledge of which tilt algorithm to implement in their tray controller, and how to position and angle the drop-off chutes. Before a single length of track had been laid down.
Too big, too expensive
Some machines are simply too big or too expensive to equip all teams with.
Take a wind turbine for instance. A wind turbine is huge and very expensive, and yet dozens of teams could really use a wind turbine to verify their work on. Teams such as the turbine controller developers, the generator and grid component developers, the park planners, SCADA personnel, and not least the commissioning and service crews.
We have designed, implemented and improved upon such advanced simulators for years. Here we are talking about big electromechanical simulators with miles of cabling, thousands of electrical connections, and a unit price of half a million USD. And yet it's a bargain compared to what it would cost to provide those teams with a complete wind turbine or even a nacelle. And when you have developed the hardware simulator, the next natural step is to make a complete software based simulator which could suffice in some situations.
Static >> Interactive
For multiple teams to do modular and parallel development you must specify the interfaces they must work up against. Taking this one step further we can help you simulate such interfaces, for instance:
- Instead of a static UI to only look at, we can build an interactive UI that changes and responds to key presses and selections for demonstration purposes.
- We can transform a template level API into an interactive API for a developer to create their module up against.
One big drawback of developing hardware-near applications is that you have to be connected to the hardware to test it.
One such example is production testing. By default you aren't able to do much development on your test sequences or instrument managers unless you are developing directly on a test station which has all the proper instruments connected to it. And for many reasons you really don't want to do that. We often build a simulation mode into our instrument drivers which, in combination with a global means to get in and out of simulation mode, enables you to develop much of your test software at your office desk.
Another example of 'office development' is when you need to start development but are waiting on long lead or very expensive hardware items. LabVIEW actually has many simulation features built into it to enable you to develop software a long way without real hardware. We can help you get the most out of LabVIEW's built-in simulation features.