Instrument simulator - command interpreter

[CT2DAC]

Hello All.

I have the need for instrument simulators, that I can use while developing and the instruments are not physically available.

Think of any RS232, or ETH instrument: dmm, motion controller, hardware interface, sensor, whatever.

I would like to have a piece of software that I would "connect" to and send commands. This sw would basically do syntax checking and reply with error codes in case of invalid syntax or with some 'valid' reply - a 'simulated' dmm would reply with a random value (maybe within a range). [I know of IVI instrument simulator, but this offers a limited number and, most often, my instruments are not IVI/SCPI compatible].

Now, the main issue is that I would like to avoid writing a specific simulator for every instrument I come across with; it would be time consuming and error prone, defeating the whole purpose of working with simulators (which is mainly getting ahead and saving time, while waiting for instruments to become available).

I would like to have the syntax specified in a text file (I know the commands syntax from the instrument manual, much like: CMD param1 -OPT1=param2... etc.). It resembles what command line interpreters, language compiler preprocessors do, based on a syntax/grammar description (abstract syntax tree?).

Searching on the net gives out a lot of stuff; however everything is specifically targeted for for windows, linux and other programming languages.

I could not find anything "programmable" or general purpose.

I came across a couple of posts - Exterface by Daklu and Gold Parser Engine by Taylorh140 - which seem to point in the 'right' direction but I can't seem to find any code to work on.

Is there anyone out there that can point me towards any kind of resource - not necessarily LabView - that can perform as I "dream of" and from I can learn/use?

 

Edited February 5, 2023 by ct2dac ct2dac

[Rolf Kalbermatter]

1 hour ago, CT2DAC said:

Hello All.

I have the need for instrument simulators, that I can use while developing and the instruments are not physically available.

Think of any RS232, or ETH instrument: dmm, motion controller, hardware interface, sensor, whatever.

I would like to have a piece of software that I would "connect" to and send commands. This sw would basically do syntax checking and reply with error codes in case of invalid syntax or with some 'valid' reply - a 'simulated' dmm would reply with a random value (maybe within a range). [I know of IVI instrument simulator, but this offers a limited number and, most often, my instruments are not IVI/SCPI compatible].

Now, the main issue is that I would like to avoid writing a specific simulator for every instrument I come across with; it would be time consuming and error prone, defeating the whole purpose of working with simulators (which is mainly getting ahead and saving time, while waiting for instruments to become available).

I would like to have the syntax specified in a text file (I know the commands syntax from the instrument manual, much like: CMD param1 -OPT1=param2... etc.). It resembles what command line interpreters, language compiler preprocessors do, based on a syntax/grammar description (abstract syntax tree?).

Searching on the net gives out a lot of stuff; however everything is specifically targeted for for windows, linux and other programming languages.

I could not find anything "programmable" or general purpose.

I came across a couple of posts - Exterface by Daklu and Gold Parser Engine by Taylorh140 - which seem to point in the 'right' direction but I can't seem to find any code to work on.

Is there anyone out there that can point me towards any kind of resource - not necessarily LabView - that can perform as I "dream of" and from I can learn/use?

This kind of idea comes up frequently and various people have tried to solve it. In the end almost everybody ends up writing a simulator for his specific device and then moves on, since there are other projects to be done that deliver income. Writing a generic simulator sounds like a good idea, until you start to work on one. First problem, lots of instruments have very different ideas of how they want to behave on invalid input, wrong sequences and conflicting settings. Some simply go into a lock mode that you have to take them out of, sometimes with a literal kick in the ass by pushing the power button. Others will refuse wrong settings and some ignore it and act like there has nothing been sent. A few try to be smart and will change anything needed to make the new settings work, even though you told them in the previous command to go into this or that mode.

The next problem is often that writing the specific command instruction file for your generic simulator is almost as trouble some as implementing it from scratch. Either simulator only supports the most trivial command response pattern and the command instruction file is trivial but the behavior of your simulation is far from close to your actual device, or it supports many modes and features and your command instruction file is getting complicated too. And almost with every new device you want to simulate you are pretty sure to need to go into your simulator to add an additional feature to support some quirk of your new device.

The end result is that there are many people with good intentions to write such a beast and none who goes beyond a simply device specific simulator, and even that one is seldom really simulating the real thing close enough to be able to test more than that your program works if everything is going right, which in reality it often doesn't.

[CT2DAC]

I fear you may be right, but I still hope for some input.

After all, there are now plenty of powerful language parsing/processing techniques and algorithms, so what can be so complicated in a trivial handful of commands and parameters?

Why not bring some of that knowledge to help poor old engineers having to do with low-tech serial devices (while awaiting delivery)?

 

[ShaunR]

23 minutes ago, CT2DAC said:

so what can be so complicated in a trivial handful of commands and parameters?

Termination characters, for a start.

I would echo what Rolf is saying. With SCPI you can get some of the way there as it standardises instrument behaviours - but even then it' has limitations.

IMO, the most expedient way to develop when you don't have the hardware is to use stubs rather than simulators. Design top-down and use stubs where you would have a driver to give you a value and an error that you can can use to develop and test  the rest of the software. When you get the hardware, you can use the stubs as an interface to a driver to massage whatever it gives into a form your software is expecting. You will, to all intents and purposes, be designing a proprietary interface for your particular software that you glue drivers underneath as and when you get your hands on them.

Edited February 5, 2023 by ShaunR

[Rolf Kalbermatter]

54 minutes ago, CT2DAC said:

Why not bring some of that knowledge to help poor old engineers having to do with low-tech serial devices (while awaiting delivery)?

Most likely because everybody says that same sentence, waits for our savior to bring the holy grail and then forgets about it after said savior hasn't arrived within a month or two. Some creating their own limited version of it but never bothering to go the extra mile to post it somewhere for others to not have to wait for that savior anymore. 😁

[Rolf Kalbermatter]

47 minutes ago, ShaunR said:

Termination characters, for a start.

I would echo what Rolf is saying. With SCPI you can get some of the way there as it standardises instrument behaviours - but even then it' has limitations.

IMO, the most expedient way to develop when you don't have the hardware is to use stubs rather than simulators. Design top-down and use stubs where you would have a driver to give you a value and an error that you can can use to develop and test  the rest of the software. When you get the hardware, you can use the stubs as an interface to a driver to massage whatever it gives into a form your software is expecting. You will, to all intents and purposes, be designing a proprietary interface for your particular software that you glue drivers underneath as and when you get your hands on them.

That's usually the way I work too. And since there are classes I usually create a base class that is a simulation, dummy or whatever you want to call it version and then a derived one that is the actual implementation, possibly with another one that is for a different similar device or over another bus interface.

My experience about trying to create a universal, generic class hierarchy for one or more device types is that it is a never ending story that will make you go back and forth over and over again as you try to shoehorn one specific instrument feature into the existing class interface to eventually notice that it breaks another feature for a different interface in the same place. Basically it is a noble pursuit to try to do that, but one that fails sooner or later in the reality.

Edited February 5, 2023 by Rolf Kalbermatter

[ShaunR]

5 hours ago, Rolf Kalbermatter said:

My experience about trying to create a universal, generic class hierarchy for one or more device types is that it is a never ending story that will make you go back and forth over and over again as you try to shoehorn one specific instrument feature into the existing class interface to eventually notice that it breaks another feature for a different interface in the same place. Basically it is a noble pursuit to try to do that, but one that fails sooner or later in the reality.

Yup. I don't go that route at all. The number of "HAL's" that I've seen that make a simple piece of software rigid and a nightmare to maintain.

I go with a simple route of wrapping a non SCPI device driver with a with a SCPI compliant "controller". The "controller" is the stub I spoke about previously when no device is available  - which then mutates into an SCPI driver when the device arrives (if it needs one). Then the application has a standard interface (string message) to all devices and only has to worry about what messages to send to which devices-you can even script multiple messages from text files!  Much easier to change a string than a class hierarchy and, if you add a device, you don't need all the boiler-plate programming that classes require-just new strings.

[CT2DAC]

It has been a long lasting problem, obviously not easy to solve.
I keep hoping somewhere, someplace, someone will have a genious idea and help solve it.

Meantime, I think Shaun's idea of stubs is still the 'least painful' way to it.

Sometimes, I still go "specific simulators" - but it's far too time consuming - most often I just 'dry code' and test only when instruments arrive. Experience helps, in this case, to avoid falling on the same old traps.

I'll dig into this, with new projects and as time goes by...

[wallyabcd]

While Rolf and other responders are entirely correct, I have in the past attempted similar exercises with some measure of success by limiting myself to certain types of interfaces at a time such as RS 232 and RS 422 or Ethernet like interfaces and using this pattern: Msg -> Msg+ Envelope -> Interface”. In fact, I last created such a thing a few months ago for an instrument simulator that supports ASTM LIS2 A2 via RS 232 as well as Ethernet.

In General, I  structure the program as follows: An initial configuration program to open and configure as many interfaces as needed and wait for communications, and to close them on command. This program was generic enough, taking all the usual parameters of RS 232 if that was the interface or Ethernet if that was the interface. This program can be standalone or part of the State machine described below. The ASTM formatting will be done in the state machine below. 

The next step is to do a state machine that detects an incoming connection or outgoing connection request, then opens and initialize the appropriate ports or channels. This state machine should have at least 6 states. Incoming connection request, outgoing connection request, Subsequent Incoming messages from a device, Outgoing communications for a device, Communication Termination request etc. Messaging then proceeds as follows:

 

Incoming: Interface->Source->Msg Reception->Envelope Decoding->Msg Decoding->Response/Handling

Outgoing:  Destination->Message->Envelope Encoding->Interface->Msg Transmission->Status

 

Envelope Decoding is stripping the communicated message from Envelope (Comm protocol + ASTM format)

Envelope Encoding means taking the Msg to be transmitted and formatting it for transmission 

The envelope(s) will contain the Destination+communications configuration + the ASTM LIS A2 overlay formatting etc.

The MSG Decoding is simply a Case structure with all the expected commands or type of messages that are expected with one reserved for exceptions, and how to decode and handle them.

The Msg Encoding is a case structure for all the different type of commands or messages that can be transmitted and how to format them.

From here on, you can see that the case structure names can be loaded dynamically from a file based on configuration or replicated for each type of interface, or even a case where a new case structure corresponding to a new interface or instrument type could be added when needed.

In general, this pattern of “Msg -> Msg+ Envelope -> Interface” is very flexible and powerful. I originally used it about 12 years ago to enable real time priority based communications on an implantable surgical instrument with distributed monitoring (15 clients with 1 master controlling the instrument)

It can greatly simplify the creation of a simulator as you can switch the envelopes or interfaces or messages even dynamically. 

Sorry no example as I will have to recreate it, maybe in the future if enough interest and time…

The important element is the pattern and understanding it, most Labview programmers can create something adequate. 

I hope this can get the juices flowing for more productive discussions