Making a sort of SDK for a controller

Thread Starter

Hyunduk Shin

Joined Feb 3, 2015
10
Hi,

Here is my brief question,

What is the standard interface method for users (not excellent programmers) to program their own software on controllers?

In other words, how they develop the interface of their devices (e.g. Keysight oscilloscope or Oriental motor motor stage) for users to program their own software?

Is it called SDK or VISA or IEEE488.2 or ASCII textual strings? script language?



The detailed question,

I am trying to study and design a controller with embedded software to control an actuator.

I have an idea that physical interface for the controller should be through USB.

But I have no idea what I should make for standard interface method through USB port.

Like popular devices manufacturer provide a kind of SDK for users, I want to develop the interface that users can program their own program.

Would you please teach me what the interface is?
 
This is a loaded question. Really tough to answer.

The deFacto standard for controlling instrumentation is LabView. Vee is Agilent's version. LabView is just plain weird. Programming is graphical in nature and each VI (or Virtual Instrument) executes when all the data is available. This means that "race conditions are possible". It also means that con-current programming is "cake". Instrument manufacturer's provide VI's for their instruments which is a high level interface. LabVIEW always want's you to use the latest version, so forget about saving to a previous version.

Another way is a touch screen interfaced with a microcontroller.

The third way is typically a PLC running the critical code and a package such as wunderware provinding the HMI.

LabView can do this too. It's easy to make a web interface, for instance.

This post https://lavag.org/topic/4001-gpibscpi-keithley-2400-sweep_i-meas-v/ has a pic of a typical Labview vi.

An SDK is a software development kit. This is typically tied to a particular compiler/archetecture.

NI-VISA, see http://www.ni.com/visa/ is a hardware abstraction layer, so USB, GPIB, serial etc. all look the same.

SCPI is a standard so that things like multimeters have a basis to start with.

An instrument can have loadable scripts, Because Windows latency sucks.

Instrumentation stated with the HPIB interface for Hewlett Packard Interface Bus. Later named IEEE-488 and with more capabilities IEEE 488.2.
The NI 488.2. So, now USB, Ethernet and IEEE 488 can be standard interfaces. Serial used to be that and we know how messy that gets.

You could for that matter have your own language or implements JAVA or Python for scripting.

Writing a device driver or a LabVIEW vi can be very hard and time consuming. I supervised someone who was trying to write one for a stepper motor controller.

Generally, the hardware can execute simple commands. An example is goto n. A high level interface might change that n to wavelength or some engineering variable.

Here http://www.tunl.duke.edu/documents/.../keithley_485_picoammeter_quick_reference.pdf are some commands before SCPI for a digital picoammeter.

Here's a contrasting blurb for SCPI. https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments

So, now the interface is more consistent and "more easily remembered". You don;t have crypic commands such as R0.

Hopefully, it's a start.
 
Let me add Strawberry Tree https://www.researchgate.net/public...and_control_in_the_animal_learning_laboratory into the "history books"

Daisylab http://www.mccdaq.com/products/dasylab.htm has probably picked up the slack.

The one thing I can say about LabView is that it supports multi-vendor (sort of). It was originally developed for us eon a Macintosh until Windows had enough power to use it. It's now cross-platform to a point with more abilities available for the PC. The growing pains were difficult. There are Linux, Mac, PC and embedded varients.

At the time I learned it, there were basically no resources except the large manual set and no standards.
One of the hard things to learn was how to handle errors when there wasn't a comprehensive error handler.
Now the idea is that if an error occurs each vi has a frame that doesn't execute and just passes the error cluster through until it's time to handle that error.

Here's a little LabView blurb: http://www.saberrobotics.org?id=34

It's now licensed for Hobbyists too.
 

NorthGuy

Joined Jun 28, 2014
611
It all depends on what you want. Arduino is a device programmable by users (not excellent programmers). Connect Arduino to your device and provide a serial interface. Is that what you're looking for?
 
Top