What is the easiest way to send/receive commands to an Arduino from a Windows PC

I have a system that I designed two years ago which uses a PC+Phidget interface to control my coal stoker stove system. All in all, there are 7 AC motors and 5 sensors. The logic is very complex so it's not something that I could easily port to a stand-alone Arduino.

For this winter, I would like to add some additional functionality to this system, such as variable PWM control of one or more of the AC motors and a remote LCD status display, something the Arduino can do easily.

Now, I can move some control logic to the Arudino but it will still need to be answerable to the PC software. Such an example would be if the program on the PC is shut down, the Arudino will need to cease operating as well. What I'm looking for is a way to use an Arduino with the PC in a similar fashion to how I use the Phidget.

With the Phidget, I prototype their commands and include a .dll file with my program. Then the Phidget commands take care of all the two-way communicating. Is there a similar thing for the Arduino that can control ports on it or send/receive messages?

Incidentally, I started hand-coding this using serial communication calls to the Windows API and I have that working in a very rudimentary way. But I'm realizing it would be a pretty decent undertaking to do it right so it is reliable (which it certainly has to be). Plus I don't want to reinvent the wheel if I don't have to.

Thanks in advance!

GB

Well, having never used phigets Im not sure how capable it is but processing is an oft used system for communicating from pc to arduino and vice versa. Of course you can use the serial monitor to send and receive but I have a feeling you need something much more sophisticated.

I don't know about Phidget either but do you mean you want a simple thing that could command I/O of the arduino from PC? Try the firmata included with arduino IDE examples. Arduino is basically listening to serial port for command words and replies.

That looks like exactly what I need, but I couldn't find a C .lib and .dll for it and I'm pretty sure that's what I need. FYI, I program in Clarion Clarion (programming language) - Wikipedia which is not very widespread, but I can prototype C libraries and use them, which is how I work with the Phidgets.

On the firmata download page, when I click on the "C++/openFrameworks" link it gives me an error. Is there any other place to get it?

I only used "Processing" software end of firmata, which is a Java-based code. You may want to start there. Download Processing from Processing.org and run the firmata code included in Processing IDE. Arduino and Processing IDEs look identical so don't get confused :wink: Once you understand how it works, I'm sure you can port it to C/C++ but please search on to see if there's downloadable C/C++ lib. You need to program your arduino to understand firmata with the firmata code in arduino example.

Firmata is simply one way to control the Arduino from a PC. Any application that can send serial data to the Arduino can result in the Arduino doing stuff based on that serial data.

It simply requires that you define and implement a protocol. A protocol is simply a defined set of words, in a defined order, that both sides understand.

You could defined commands like "PrettyPleaseSetPin 9 to on!" (or "9 on!") or "ItsHotTurnPin 9 downTo 45!" (or "9 45!").

The PC application sends the commands. The Arduino reads the serial data, until the end of packet marker (! in my examples) arrives, storing the data in a string (NULL terminated char array) or String. When the end of packet marker arrives, parse the string (or String) and determine what to do. Then, do it.

PaulS, that's what I started doing on my own, but got to thinking that such a concept had to have already been developed. Apparently it has, but I'm not sure that I'll be able to utilize firmata in Clarion (the language I wrote my system in).

The biggest challenge will be to get it so that it solid and reliable. It will have to be able to handle communication problems (garbage, dropped data, etc.). Both ends will have to listen for verify responses when they send data and so forth. So it won't exactly be as simple as sending a command and parsing it on the other end. Alas, I'll just look at it as another learning experience :slight_smile:

As you mentioned, you are asking for the 'easiest way' to handle serial communications. Besides the terminal solution (not exactly what you want, but you're running in ten minutes), there's programming: Write a custom program in your favorite (ie easiest to use) language. Someone pointed out Processing can do that, as can C and probably visual basic - just search on your language for tips. Some compilers even include ready made components for that, so serial is even easier to program.

Apparently it has, but I'm not sure that I'll be able to utilize firmata in Clarion (the language I wrote my system in).

Probably not.

The biggest challenge will be to get it so that it solid and reliable.

Doing this is not as difficult as you might imagine. The first thing to remember is that serial data is delivered by USPS, not UPS. UPS guarantees to deliver your package. USPS guarantees to try to deliver your package. So, you must anticipate lost bytes.

The second most important thing to remember is that by Arduino's standards, serial data delivery is sssssslllllllloooooowwwww.

Therefore, some start of packet marker, some packet size, some data, some checksum, and some end of packet marker need to be used to ensure that what was received was what was sent. If incomplete packets are not catastrophic, the packet size and checksum can be dropped, to minimize data being sent. The start and end (especially end) of packet markers are the most crucial to delimit a packet.

Both ends will have to listen for verify responses when they send data and so forth.

Depending on the integrity of the data, the Arduino could compute a checksum in the same way as the sender. If they don't match, the Arduino sends a NAK. If they do, the Arduino sends an ACK. On receipt of an ACK, the PC application sends the next packet. On receipt of a NAK, the program resends the current packet.

There are plenty of examples on the web of computing checksums, and ACK/NAK sending. TCP/IP is built on this concept, and it works for virtually everything sent via the web.

PaulS:
Therefore, some start of packet marker, some packet size, some data, some checksum, and some end of packet marker need to be used to ensure that what was received was what was sent. If incomplete packets are not catastrophic, the packet size and checksum can be dropped, to minimize data being sent. The start and end (especially end) of packet markers are the most crucial to delimit a packet.

Well, I’ve decided on a fixed length for each command (4 bytes) and will use a “>” as a start marker for commands sent from the PC to Arduino and “<” for vise versa. Since I’m only sending 5 bytes per communication, I had originally intended to just echo the commands back to the sender as my error checking, but I’m going to guess that a checksum is much more reliable and accurate, right?

Unfortunately Clarion does not have ready-made functions for serial communication, but I can prototype the Windows API calls (CreateFileA, BuildCommDCBA, ReadFile, WriteFile, etc.)

A final bit of advice I am wondering about is – is using the Arduino’s USB port for serial communication ok? Or would you recommend I use the pins and connect directly to a hardware serial port on the PC? Personally I have encountered some flakiness with the USB/COM driver.

Since I'm only sending 5 bytes per communication, I had originally intended to just echo the commands back to the sender as my error checking, but I'm going to guess that a checksum is much more reliable and accurate, right?

Not necessarily more reliable and accurate, but it is faster to compute the checksum and compare that to what was received, that to send the whole received stream back and wait for confirmation that what was received by the Arduino and sent back to the PC was correct.

I've written a number of pages about communicating between Arduinos and PCs over a serial channel. I suspect you are past most of the issues I've covered, but give the pages a skim... you may pick up some Good Stuff even now? And newbies drawn to this thread will, I'm bold enough to hope, find lots of help....

tkbyd:
I've written a number of pages about communicating between Arduinos and PCs over a serial channel. I suspect you are past most of the issues I've covered, but give the pages a skim... you may pick up some Good Stuff even now? And newbies drawn to this thread will, I'm bold enough to hope, find lots of help....

Sending Data to Arduino IDE, simple answer- art4SeIntro

hah, sure I may be past some of it, but I know enough to know that I can never take for granted that I know all I need to know! (if you get my drift). For instance, I did skim over your page and right off the bat learned that apparently I can't just connect my Arduino up to the PC's serial port. I hadn't tried it yet, but it's something I was thinking I may want to do for this particular project -- so it was definitely worth the skim!

PS: I've read over some of your other articles already. In particular I was interested in communicating with 1-wire eeproms on toner cartridges, but before I involved with actually trying it, I got temped into other projects. I also started to think that it was probably going to be much more complicated than talking to temperature sensors (I imagine toner eeproms communicate with encrypted data or something so it's not easy for "just anybody" to figure it out :roll_eyes:)

PaulS:

Since I'm only sending 5 bytes per communication, I had originally intended to just echo the commands back to the sender as my error checking, but I'm going to guess that a checksum is much more reliable and accurate, right?

Not necessarily more reliable and accurate, but it is faster to compute the checksum and compare that to what was received, that to send the whole received stream back and wait for confirmation that what was received by the Arduino and sent back to the PC was correct.

In the end, I modified my code so I can send variable length data (up to 100 characters per command). I didn't want to echo that much data so I did a very simple checksum: I loop through all the bytes to send and one by one add them to a variable that is also a byte. I then send that byte at the very end of the command and then calculate it on the Arduino and compare. I realize it doesn't guarantee 100% accuracy but I think it'll be sufficient for my purposes.

Given this:

All in all, there are 7 AC motors and 5 sensors. The logic is very complex so it's not something that I could easily port to a stand-alone Arduino.

but now looking at the considerations of ensuring reliable comms, any thoughts about revisiting the port - how complex is it?

wildbill:
Given this:

All in all, there are 7 AC motors and 5 sensors. The logic is very complex so it's not something that I could easily port to a stand-alone Arduino.

but now looking at the considerations of ensuring reliable comms, any thoughts about revisiting the port - how complex is it?

Heh, working out this communications took about 8 hours. Rewriting the whole PC control system on the Arduino would take probably 10x that considering I am not incredibly fluent in C! Then I'd still need serial communications if I wanted to be able to datalog, display real time status, and graph everything like I do now :astonished:

I think I have it working pretty well now. I do plan on offloading some small bits of control logic to the Arudino as a failsafe in case the PC crashes, but I still plan to control most of the Arduino's inputs/outputs from the PC by the serial commands.

Use firmata protocol (http://arduino.cc/en/Reference/Firmata), which has ready common-used methods: to set/get pin value and many others. There is library in C for the board and Processing library for Java. Unfortunately, the last has processing serial and processign UI dependencies, so you can use 4ntoine/Firmata instead (GitHub - 4ntoine/Firmata: Firmata pure Java implementation)