Serial / Command Line Interface: list of commands? And is it a complete interface for controlling 100% of DNA 200 functions and the basis of EScribe?

[TheBloke]

Hey guys,

I was very excited to see two things in EScribe:

1. References to the Serial Command Line Interface, apparently a CLI for communicating with the DNA 200?
2. The fact that, on installation of EScribe, it installed a USB-to-Serial driver (not a generic one, one created by (for) Evolv.)

This gave me the following thoughts:

1. It seems possible that all communication between host and DNA 200 is in the form of CLI commands.
2. Suggesting EScribe is a UI on top of a system of sending text based commands and parsing their responses?
3. And therefore, everything EScribe can do can also be done via CLI commands?
4. Further, it appears the host-to-DNA communication is a generic serial interface, wrapped in USB-to-serial
5. Therefore, any host computer which can host a USB-to-serial driver (ie., all of them: OSX, Linux, Android) could communicate with the DNA 200, if we knew the complete list of CLI commands to use?  (And possibly, if an appropriate driver is made, depending on what Evolv's own driver does that's special.)
6. And therefore, it would be easy to re-create ESCribe on multiple platforms; creating a new cross-platform UI which, as I am assuming for the PC version, is simply a pretty UI on top of a CLI command/response system to the device? 

I would be most grateful if someone from Evolv could confirm if my assumptions are correct, in particular items 3. and 5. above - can the CLI do everything that EScribe do, and is the PC-to-DNA interface just USB-to-serial as the driver installation seemed to suggest?  Looking at the driver files installed by EScribe, it does appear to be generic USB-to-Serial, but perhaps with some special setup required - such as creating multiple serial ports (separate output and input channels?  multiples of each?)

I would also love to be able to see a complete list of the CLI commands available via the Serial interface.  Is there some documentation for this, or if not is this something that's planned in the near future?

My interest in this is two-fold:

1. In general, the idea of a cross-platform EScribe, as I discuss above
2. But much more pressing than that, I would love to be able to communicate with and control the DNA 200 via scripted CLI commands.

I am a UNIX/Linux architect and developer of some experience.  Therefore a command line interface is always my natural preference.  I am planning to do some detailed testing and analysis with and of the DNA 200, exactly the sort of stuff enabled via the Research system.  

It's wonderful that I can do that in EScribe.  But I hope to be able to move outside EScribe, communicating with the 200 via external scripts.  This will facilitate automation, scheduling, and logic: the ability to create a series of tests, with permutations and conditions, and run and re-run them easily and repeatably.  

I would therefore love to be able to set up an interface to the 200 outside of EScribe, treating the board as a generic serial device to which I send commands and receive responses.

If no such command list currently exists, and it's not a priority for Evolv to create one, then if it is confirmed that EScribe is simply a UI wrapper to a text command-based system, I will see if I can snoop on the USB-to-serial interface and log all the commands being sent and their responses.  That should be a quick and easy way to create a list of all the supported commands and examples of their output.

Thanks very much.  I can't wait to get my board up and running and start experimenting with all this!

[John]

Well, yes and no. 

Anything you can do in device monitor is a wrapper for command line commands. So all operation of the device can be done via command line. You can make it fire, record, log, etc. Anything in device monitor is accessible that way. 

There's a serial terminal in Escribe. 

The commands are plain text and respond plain text. So that much is particularly easy. 

We built it that way especially for automation. In, say, a research setting you want your smoking machine to just run, rather than have to have a lab tech hit buttons. 

We have a list of commands for developers. It is not particularly up to date, and we're unlikely to update it until after the official launch (priorities) but we can send it to you. 

Loading firmware is encrypted, and the settings bake to a binary file for upload, so that side of it isn't readily accessible this way, but all operation and montitoring commands and queries you can get to.

The serial driver is proprietary, but the default is serial tunneled over HID, and that is totally standard, so if you can handle that small extra level of abstraction, there's no reason it won't talk to linux without having to write a driver. 

Hope that helps.

[James]

I should add that while the Windows serial driver is proprietary, the protocol it speaks is standard USB CDC serial. So Linux will recognize it without a driver. Because the device is composite, the CDC serial must have an Interface Association Descriptor, which makes the serial not work with Mac OS X (no IAD support). But, the HID-tunneled serial will work on every platform.

[TheBloke]

Thanks very much for the super fast response John and James!

That's great to hear.  Firmware upload is no concern at all for what I want to do, which is the sort of automated research/testing that you describe. It would be useful in a theoretical future cross-platform EScribe system, but I suppose if such a system ever starts being developed by the community then we could discuss with you a way to port that feature at that time.

Changing settings would be nice right away, or at least I am assuming it would be.  I haven't yet fully researched what I can do via the Research interface.   But for example, I can definitely imagine wanting to vary pre-heat settings between tests.  So it would be nice if (at some point) that binary format was released, so I/we could write code to create our own settings bundles and upload them prior to triggering a test.

I was thinking maybe Presets would be a way to go - if the Research system allowed switching presets prior to firing, I could pre-configure up to 8 tests in 8 presets and switch between them that way.     But a quick glance at the manual suggests it doesn't allow changing presets?  I can change temperature, power and other things but not tell it to switch to a preset first?   Or perhaps there's an undocumented CLI command for that?

Anyway I don't want to take too much of your time now.  I hope to have my board up tomorrow or the day after, and I can learn a lot by playing.  What you've told me is already immensely encouraging.

If you would be able to send me that list of CLI commands that would be very much appreciated - I understand it might not be complete, and that it won't be a priority for you to update it any time soon.  That's all fine.  Just whatever you have will give me more than enough to experiment with I'm sure.

Thanks again guys!  This is going to be so amazing for experimentation, it's awesome.

[TheBloke]

James said:

I should add that while the Windows serial driver is proprietary, the protocol it speaks is standard USB CDC serial. So Linux will recognize it without a driver. Because the device is composite, the CDC serial must have an Interface Association Descriptor, which makes the serial not work with Mac OS X (no IAD support). But, the HID-tunneled serial will work on every platform.

Excellent, thank you!  I will definitely experiment with Linux as soon as I can then, via VMs to start with.

[John]

You can switch profiles via command line. Profiles are fairly new. 

[VapingBad]

Nice: plain text scripting , great line of inquiry @ThankBloke thanks I may have to have a play when mine drops.


The gift that keep on giving

[SSV]

I would love to have that command list as well....some automation would be very helpful in running PTC calibrations......is there a way to extract clock reference Via serial interface?  This would be helpful when locking test gear (temp and resistance) + dna200 into matlab for time-correlated data-logging

[Mad Scientist]

I'd also be very interested in the interface specs. I really want a wireless interface between the PC and the DNA. I can do a wireless serial interface. Hopefully for this it's a couple of USB to serial converters, a couple of PICS and the radios? Is all the data communication CLI?

[ClintMaas]

Mad Scientist said:

I'd also be very interested in the interface specs. I really want a wireless interface between the PC and the DNA. I can do a wireless serial interface. Hopefully for this it's a couple of USB to serial converters, a couple of PICS and the radios? Is all the data communication CLI?

I really want a way to go wireless as well.  I just haven't found anything easy (small dongle).

[ClintMaas]

I do industrial programming and it would be really cool to be able to grab serial data and do long term trending on a factorytalk historian.   Not that I need this but would be interesting.

[James]

Here are the main control commands. Enjoy

Fire: F=#S
Set Power Setting: P=#W
Set Temperature Setting: T=#C or T=#F or T=?
Set Profile: M=# (1 to 8)

Get Power: P=GET
Get Power Setting: P=GET SP
Get Temperature: T=GET
Get Temperature Setting: T=GET SP
Get Voltage: V=GET
Get Current: I=GET
Get Profile: M=GET
Get Battery: B=GET
Get Battery Cell: B=GET CELL # (1 to 3)

The Device Monitor works by issuing serial commands, so really anything it can do can be commanded.

[Mad Scientist]

ClintMaas said:

[QUOTE=Mad Scientist]I'd also be very interested in the interface specs. I really want a wireless interface between the PC and the DNA. I can do a wireless serial interface. Hopefully for this it's a couple of USB to serial converters, a couple of PICS and the radios? Is all the data communication CLI?

I really want a way to go wireless as well.  I just haven't found anything easy (small dongle).[/QUOTE] There are a boatload of chips and hybrids available. Years ago I did a temperature telemetry project using radios from a now defunct supplier. The radios were about half the size of a thumbnail. An eight pin PIC and DS1820 and the whole shebang was less than a cubic centimeter, not including battery. I haven't worked with any of the new crop of stuff yet but surveying what's out there, they have hybrids with the radio chip including an ARM core. Basically single chip radio and processor with a few discretes. Very tiny. Once I select the parts and get something working, I'll post back with what worked. There's a lot out there, really amazing stuff. Maybe make the DNA 200 it's own IoT WiFi web enabled mod lol. I wished for plug and play but there seems to be nothing available.

[Mad Scientist]

James said:

Here are the main control commands. Enjoy

Fire: F=#S
Set Power Setting: P=#W
Set Temperature Setting: T=#C or T=#F or T=OFF
Set Profile: M=# (1 to 8)

Get Power: P=GET
Get Power Setting: P=GET SP
Get Temperature: T=GET
Get Temperature Setting: T=GET SP
Get Voltage: V=GET
Get Current: I=GET
Get Profile: M=GET
Get Battery: B=GET
Get Battery Cell: B=GET CELL # (1 to 3)

The Device Monitor works by issuing serial commands, so really anything it can do can be commanded.

Fantastic, thank you! Any info on timing? I'm assuming it's all "as fast as it can" but are there more than incidental timing considerations for performing, for example, a quick succession of T=GET transactions to make a temp plot?

[James]

Only thing I can think of, when doing GET requests, do (1) 'send query, wait for response, send query, wait for response, send query, wait for response'.

Don't do (2) 'send query, send query, send query, wait for response, wait for response, wait for response'.

It won't send a response until its send buffer is empty, so you won't improve update rate by doing (2) (in fact, you may fill up the DNA's receive buffer, waiting forever to send, while the DNA is waiting to finish sending back to you...) and your code will be more complex. Do it the simple way, (1).

[Mad Scientist]

James said:

Only thing I can think of, when doing GET requests, do (1) 'send query, wait for response, send query, wait for response, send query, wait for response'.

Don't do (2) 'send query, send query, send query, wait for response, wait for response, wait for response'.

It won't send a response until its send buffer is empty, so you won't improve update rate by doing (2) (in fact, you may fill up the DNA's receive buffer, waiting forever to send, while the DNA is waiting to finish sending back to you...) and your code will be more complex. Do it the simple way, (1).

Yes, I get that, but what is the latency of each GET transaction? So in your explanation above, what is the timing of the "wait for response"? I.e. how long is this wait? Would it be practical to obtain real time data for plots through this CLI or is it too slow? If it's too slow, can we get specs on the fast interface? I'm trying to come up with a "least pain" way to implement a wireless link between the DNA and the PC. If the CLI is fast enough to get the data out of the DNA for plots, that would seem to be perfect. As a seat of the pants guess, I'd anticipate wanting to obtain at least 30 data points per second allowing for 3 data types at 10 interleaved points per second each (like temp, power, resistance or along those lines). Is that like way slower than the thing can spit out the data or would I be bumping up against limitations of the DNA CLI's ability to parse the command, get the data and send it? Thanks very much for your help!

[James]

Device Monitor demonstrates pretty well what can be done. It's actually limited by its paint code being on the same thread as the query code (and Microsoft's .NET Windows Forms not using hardware acceleration for drawing...). Be kind to it ( at a certain point you might be slowing it down), but you can push substantially more than 30 queries per second.

You can also set Serial Output in the Research tab to CSV (Excel). That is a 50 Hz output of all of the important values. It did slow the device down by a few percent in my tests (a candidate for future optimization), but you can get a boatload of data points...

[Mad Scientist]

James said:

Device Monitor demonstrates pretty well what can be done. It's actually limited by its paint code being on the same thread as the query code (and Microsoft's .NET Windows Forms not using hardware acceleration for drawing...). Be kind to it ( at a certain point you might be slowing it down), but you can push substantially more than 30 queries per second.

You can also set Serial Output in the Research tab to CSV (Excel). That is a 50 Hz output of all of the important values. It did slow the device down by a few percent in my tests (a candidate for future optimization), but you can get a boatload of data points...

Excellent. Thanks!

[AllenH]

Ok, this may be a bit of a dumb question here (coming from a different computer platform)- what would I need to use to send these commands and receive output?  Can I send via a terminal program or similar and still have the device record in escribe?

[James]

AllenH: Yes you can. EScribe uses USB HID to communicate, leaving the USB serial port free for your use. You can issue commands as well as queries.

[AllenH]

That's awesome, James!  Thanks!!  I'll start playing a bit!

[AllenH]

Hi again, everyone!  I was wondering what you're using to send commands to the device?  I'm attempting realterm, but not sure about baudrate parity etc., or if those are even necessary.  New at this on the windows side, so I'm a bit out of it.  [and another complication I'll share if I can't do this in the standard way... first step learn the standard way. ]

[John]

Well, for real simple stuff there is a terminal built into Escribe... 

[AllenH]

Oh!  You guys have thought of everything!!!  

[AllenH]

Ok, only problem with this is that device monitor doesn't let you click anywhere other than the monitor, and the terminal doesn't let you click anywhere but the terminal... so I can't give commands and watch the output.  I'd love to be able to have both up, or a simplistic terminal within monitor.  [Just a small suggestion.]

Update- well, I was able to do most of what I wanted to semi-manually via the puffs and temp set interface on device monitor.  My only problem is now I think the full test I wanted to do is more complex.  I'm going to have to think about this a bit more.    Awesome that I was able to try it though!