Programming UI: Were to start?

[dubbleUJay]

Guys, I'm trying to get my mind around a possible User Interface for the Engine Data Logger/Controller with Arduino.
1stly, I don't know programming! Although I understand some of the coding of the AVR in the Arduino UI which is ultimately C/C++ as I understand it???

From Wikipedia: http://en.wikipedia.org/wiki/Arduino
Arduino is an embedded system platform based on a simple open hardware design for a single-board microcontroller, with embedded I/O support and a standard programming language.[1] The Arduino programming language is based on Wiring and is essentially C/C++ (several simple transformations are performed before passing to avr-gcc).[2] The goal of the Arduino project is to make tools available that are accessible, low-cost, low capital investment, flexible and easy-to-use for artists and hobbyists, particularly those who might not otherwise have access to more sophisticated controllers that require more complicated tools.[3]

Modified- Something I think I should add from the Wiki:
Arduinos themselves generally do not have networking facilities, but it is common to combine one or more Arduinos with a networked host, using the Arduino as hardware controllers and the host as a network or user interface. Host interfacing is simple, since the host software may be written in a variety of languages. A popular language is Processing, but other languages that can access the serial connection are Max/MSP, Pure Data, SuperCollider, ActionScript, and Java.[4]



I know most of you would probably be biased towards your personal favorite language, but which one to chose from???
It seems that most other projects using Arduino are using Java to write UI for PC's for it, so it would seem that Java is the way to go unless you think otherwise?

2ndly then, are there any free/open-source programs out there to help me get started, most seems to be orientated towards web-page design? Maybe something with a visual interface as well, or am I asking to much for free

The UI would calculate & display values derived from data logging, but also sent some commands to the controller(s).

I'm not planning on writing this myself, but would like to at-least seem that I know a little of what I'm talking about, to a certain extend and within reason

Anything welcome guys,
dubbleUJay

[mobile_bob]

as we all seem to be going in a variety of directions, i don't know whether you could use this to get your interface
from pc to your microprocessor, but i know i am planning to do so with my system.

http://cgi.ebay.com/FP08-8-Relay-Board-Kit-for-PIC-AVR-8051-VB-LabVIEW_W0QQitemZ160381394462QQcmdZViewItemQQptZLH_DefaultDomain_2?hash=item255779de1e

this is the relay board, but the provided software has some interesting capabilities that might be useful?

i can see how i can provide a level of oversite and control of my master/slave architecture with a pc via the parallel port
and i would expect it might also be possible to increase the capability with added parallel ports? 

in any case this ebay offering is one of several where there are some interesting interface software included in the price
and the relay board itself is also useful for a variety of operations,

what i am thinking is if the software can provide I/O out of the parallel port then it shouldnt be too difficult to make it ttl compatible
with the I/O of your favorite microcontroller?  maybe with opto isolators if there is a problem with the ttl 5 volt limit?

i went with another supplier of these boards and his software does not include the timer functions, but simply the switch panel
that i can at least reassign names to.

i am thinking of going ahead an ordering one or more of these boards to not only get the software but also get the hardware which
i know will be useful as a driver from the microcontroller to the outside world of higher power switchgear.

for the price it is hard not to at least consider or explore the offerings possibities, and perhaps we can find from the seller
whether or not the author or the software could be persuaded to allow us to modify its capabilities to fit our needs, or maybe
he would be agreeable to modifying the software for a nominal fee to fit our needs? 

fwiw

also, i have no idea what standard pc architecture limits might be on the number of parallel ports, however i do remember
my old ibm microchannel machines could address up to 16 such ports, x 8 channels each would provide for a pretty large system.

much larger than my needs anyway

bob g

[dubbleUJay]

Thanks Bob, I've got to read over this a few times, but just remember to add the $10 to get the LabView program and try to find out which version it is?
It might be an older one not supported with the new National Instrument programs if you might need that later.
With your existing hardware (I saw on another thread) this would probably work for you. (I'm also a "relay-logic" bloke, I thought we could do some amazing things at the time )
I'm sure I saw some software switchable serial&parallel port extension boxes a few years ago?
Also the USB-232 drivers one gets nowadays can make a USB port seem to be 232 to the PC. (With USB-232 hardware converters) Maybe one gets parallel port ones too but if it were me, I would have tried to get serial relay boards maybe, the PC's we get here don't even have Printer ports any more!
dubbleUJay

[mobile_bob]

parallel ports seem to be disappearing here on new puters as well, maybe if it works out for me i should go out and buy
a few parallel port boards to plug into an available slot in the motherboard down the road?

or maybe i need to get busy and build an industrial pc, hardened for my use and built to last till such time i either croak
or something better comes along.



bob g

[Westcliffe01]

WJ - Where are you located ?  I know ZA, but regionally ?  I was born in Newcastle, moved to Bethlehem when I was only 1 or 2 and then the family had a brief 6 month stint in JHB before quitting that and going to Vredenburg.   That lasted until the boys reached high school age and there wasn't much choice of schooling and my dad got a new boss who was going to give him a heart attack.  Next move was PE until I graduated high school and the 2 years in the SADF.  After that I ended up in Mossel bay for the refinery project, after which I finally started on automotive.   Left ZA in 99 and moved to the european development center in Germany for 3 years after which I came to the US to support the 2007 truck programs.   If you own a 2007 or later Ford, Silverado/GMC or Dodge Ram with a diesel engine, the emissions system was built on equipment I developed.

Regarding your application, the first thing I am guessing is that you don't want to spend a ton of money.  So looking at open source is going to be a big thing.  Familiar with Linux ?  Take a look at Qt, one of the most commonly used software development environments used for user interface development today.    http://qt.nokia.com/products/licensing
Considering that this will be for your own use or within a very limited group with no commercial interest, a free set of software and compliance with the rules should be no problem.

The other thing is that there is a large community of software developers out there, so it may not be too difficult to find pieces of code that you can re-use for your application.  The great thing about Linux is that all the major tools anyone needs are available for C, C++, Python, Java, SQL, HTML, you name it.   Try doing that for Windows and you would have to plonk down several thousand $.

But to clarify:  If all you are trying to do is some data acquisition, there is an easier way.  Look at this system: http://www.mccdaq.com/usb-data-acquisition/USB-1208-Series.aspx  

They have a USB based data acq system for 8 analog channels, 16 digital IO including software for less than $200.  No code to write, you will have to figure out what signals you want to capture and how to format (scale) them properly.  You may need to build a few small circuits that for instance convert a pulse train to a voltage for RPM, for instance.

It all depends what ypu want to do and how soon.

[rl71459]

I can vouch for that MCC USB DATA device... I have 1 @ work... It is real handy. If you have a skilled programmer (That is not ME) they can make them do a great many things Quickly. Even at my level it was very helpful for me to be able to custumize it with the included software to do what I needed.

Rob

[dubbleUJay]

WJ - Where are you located ?  I know ZA, but regionally ?

Hello Westcliffe01.
I presently situated in PE, although I've also been all over the place like you. (In ZA that is)
Born in Wellington in the Boland (Close to Vredenburg, use to play school rugby against them)
Use to have great holidays at The Point in Mosselbay.

I'm currently pre-occupied with some personal problems and as soon as they are sorted, I can get my thoughts back to the group and the project I was busy with.

Thanks for the suggestions on hard/software, I'll look into it.
Regards,

[AdeV]

Just to (belatedly!) answer the original question on this thread...


IMHO, any data acquisition/control system breaks down into 4 discrete components:

1) Data Sensing
2) Engine Control

Both of the above can be handled by a suitably equipped Arduino or PIC or any other kind of embedded Microcontroller (MCU).

4) Reporting and Management - the bit where you see what's going on & you get to send commands to the MCU.

The above can be handled in a variety of ways, languages, and so forth. For personal preference, I would implement on a PC using VB.Net to create a web-based system (so it can be used/viewed remotely). Although I also have plans to write a control/monitoring system for a 30-year old Z80 based computer, purely for my own edification.

The astute of you may have noticed something missing above.... it is:

3) Communication.

IMHO, this is the single most important element in the system. I also think it should be the one element that we try to keep as standard (in computer terms) as possible; and, so, I'd recommend a good ole' 9600baud RS232 serial connection, running an open-source comms protocol which covers all of our immediate needs, yet is expandable for all the stuff we've not thought of yet.

I notice in another thread that Daryl (Crumpite) has made a start on such a comms protocol, and it would be interesting to see where he's up to with that one.

When it comes to serial comms, I can write a windows-based service in .Net which will send/receive serial data. I've written several over the last few years, which interface with various PABX systems, so writing one to interface with an engine ECU won't present any challenges. I'm sure we can find someone capable of creating a Linux equivalent; and that covers 99% of the likely user base. It also allows masochists like me to interface it to ancient history.

Serial comms, for all the rumours of its demise, has been going strong for over 30 years, and shows no signs of quitting yet. And, with USB-to-RS232-serial converters, and USB-to-TTL-serial converters widely available, it's probable that serial comms will last another 30 years yet.

Thoughts on the above welcomed, as always.

[Crumpite]

Just to (belatedly!) answer the original question on this thread...

<snip>

IMHO, this is the single most important element in the system. I also think it should be the one element that we try to keep as standard (in computer terms) as possible; and, so, I'd recommend a good ole' 9600baud RS232 serial connection, running an open-source comms protocol which covers all of our immediate needs, yet is expandable for all the stuff we've not thought of yet.

I notice in another thread that Daryl (Crumpite) has made a start on such a comms protocol, and it would be interesting to see where he's up to with that one.

<snip>

Thoughts on the above welcomed, as always.

AdeV,

The only problem with 9600 baud is the cable length problem:
Several folks on the list use *very* remote sites for their power generation and other systems.
Another problem is having a very limited power budget for some applications.

However, you have hit the nail on the head when it comes to using serial communications, IMHO 

I was planing on using plain serial communications via a current loop, with the baud rate determined by the length of run and the power budget.

Progress on the system is halted at the moment, due to loosing the EE I was working with on this system.
I'm still struggling with a learning a programming language to implement a GUI for the system (Python)
The reason I'm using Python is that it's an open source language that works across a multitude of operating systems.

Crumpite

[AdeV]

The only problem with 9600 baud is the cable length problem:
Several folks on the list use *very* remote sites for their power generation and other systems.
Another problem is having a very limited power budget for some applications.

Does standard h/w exist to convert current-loop into RS232 signalling & vice versa? If so, I guess the actual electrical implementation becomes less of an issue.

I'm curious about the low power budget - surely this could run off the generator's starting battery without significantly draining it? Especially if the MCU side had a low-power standby mode; and was only brought to life when the genny is required (and, for the most part, therefore, generating)?

However, you have hit the nail on the head when it comes to using serial communications, IMHO 

I was planing on using plain serial communications via a current loop, with the baud rate determined by the length of run and the power budget.

I guess variable Baud is not a problem; the software on either side can adapt to that. Electrically, I'm not sure what the differences are, but I don't suppose it matters hugely? The MCU would be outputting "serial data in XYZ format", and the other end would be reading "serial data in XYZ format". Although I reckon RS232 is the way to get that data from A to B, there's no reason a current loop system couldn't do so either.

Progress on the system is halted at the moment, due to loosing the EE I was working with on this system.
I'm still struggling with a learning a programming language to implement a GUI for the system (Python)
The reason I'm using Python is that it's an open source language that works across a multitude of operating systems.

Looks like Python will talk to serial ports easily enough The problem with all cross-platform GUIs is, the actual GUI tends to be implemented differently. I'm wondering if you'd be better looking at Java... although having said that, I wonder if Java has access to the underlying hardware (i.e. the serial port).

For multi-platform GUIs, I'm a big fan of the web-based application. Pretty much every OS on the planet has a web browser, and provided you're not too heavy on the local scripting, you can pack massive functionality into even fairly old & primitive computers. I'd be tempted to use apache+php if I were a Linux developer, but as a Windows dev I'll use .Net.

[Jedon]

I too would use a web interface ( well have actually ). If you don't user the newer .NET libraries you should be able to use mono to run it on any linux as well.
I hook the serial board output up to a serial to ethernet converter and plug it into the network.
I use a windows service with threads listening on async sockets for incoming data.
Web client writes requests for the boards into a SQL database that the service is listening to and will then pass the commands on to the appropriate board.