Monad

One presentation I found very exciting yesterday was on the new Monad technology. Although it isn't quite correct to say this, it is the easiest to understand - Monad is the replacement for the Windows command line interface, or shell. In truth, the Monad engine is hosted by a command line window (MSH) and can be hosted in other systems (as it is in the new MMC system), but most people see Monad and the shell as one. We'll stick with that for now.

It can be hard to fully understand the power behind Monad - I've seen it before but it wasn't until the presentation that I really began to understand the power of this thing.

The simple description is that Monad allows command line access to the .NET framework and other .NET libraries. If you have ever created or used command line interfaces (ls, cat, grep, etc.) before to create scripts, you've probably experienced the pain of trying to parse the text output of one tool correctly to feed it into the next tool (usually lots of perl and regex). Monad eliminates this because the output of any command is an object - and thus "piping" the output of one command into the next is really just handing objects around. The efficiency and reliability improvement is profound.

You can begin to imagine the ability to interact with just about any system on Windows via the command line, with standardized parsing, documentation and response.

On the developer side, this is also a major win. I've spent most of my career creating APIs for different things (devices, server applications, etc). But once you have the API, you still need to go off and create an executable that can take command line arguments to pass parameters and select methods. This means creating your own parser for APIs over and over again. I've heard Unix command tools described as an example of a thousand crappy parsers. It isn't far from the truth (although the tools themselves are quite good).

By creating small wrappers around your .NET API (called Cmdlets) you can expose your API in a nice OO manner and all parser work is handled centrally by Monad. This should really lower the bar for more software to provide command line interfaces. And once that happens, the users are empowered because they can now interactively work with the software to "try things out", as well as create scripts to automate common tasks, such as deployments, configuration, diagnostics, etc.

So, what do you wish you could do with NI products and a command line/script interface? Let me hear from you.

Comments

[Michael Ashe]

I wish we had an interface into assigning drivers in MAX for items like IEEE-1394 cameras. Recently we tried to use Firewire extension cables and/or hubs with Basler A601/2 cameras. We had to assign the NI 1394 driver to each camera. All was fine until power down or reboot, then the cameras were no longer recognized until we went into MAX and manually reassigned each to the NI driver. This is not something we could expect the customer to do. They need to turn the machine on and run. We were told that at this time and for the short term future no programmatic interface into MAX was possible.
Thanks,
Mike

[Brian Tyler]

I can't speak specifically on MAX or the team's workload, although you can be certain I'm talking to them about Monad. Unfortunately, Monad as a released product is still a ways out.

[Johann]

Sounds like a problem with the IEEE 1394 Camera driver and not the MAX interface. Can you continue this thread on the discussion forums (http://forums.ni.com/ni/board?board.id=200)? I believe resolution will come swiftly with more eyes (NI engineers, Alliance members, and customers) on the problem.

[Michael Ashe]

Plausible. We noticed the problem only when we used an extension cable or 1394 hub to connect the camera. When we went direct, with one standard 1394 cable we never had a problem.
At the time I did go to the NI Forums and Scott (of NI) told me of the issues and we traded posts and emails until it became apparant that we could not configure MAX to solve the problem. That was the motive behind my post to this blog. My point was, and remains, that whereever the problem lies, a programmatic interface into MAX for reconfiguration would have let me write a workaround or error handler that would fix the problem each time and move on. It turns out that there was a thread like this (http://forums.ni.com/ni/board/message?board.id=200&message.id=3568&view=by_threading&page=2)
recently enough that shows the 1394 driver 2.0 solves this problem. But I still want the API into MAX. It is a general need and has shown up on other projects. The tendency to only allow configuration with a graphical, neat tool like MAX is a problem. I had a project where the the customer wanted to use Fieldpoint and so did I. But after testing we found out that under certain conditions the configuration of the FP modules with the system got lost and the only solution was to manually go back into the nifty graphical tool. This was unacceptable to the customer and they went with Opto22 modules instead. I still got the software work, but lost the FP hardware sale and so did NI.
A Monad style interface into MAX would be great. Better, expose the API using standard application invoke/property nodes.

[Johann]

All aspects of camera configuration in the MAX provider happens through API calls in the camera driver. MAX is only a nifty frontend, but it is not required to work with the camera driver. We have other situations where some application replaces the functionality of MAX. Applications like Vision Assistant and Vision Builder for Automated Inspection.