next topic »

[on:]

I'm working on a program where I can control up to 4 channels of lighting. Lighting current source is independent of the arduino and is already developed hardware. The controller will have the following control methods:

1. TCP/IP server -- user interface for use over a browser
2. USB GUI -- user interface for serial users (also low-level setup for the controller)
3. Serial command interface -- users can control the unit over serial commands rather than software

Control functions include:

1. Channel settings for 3-4 channels
2. Memory to save settings
3. possibility for pre-set configurations (call up stored channel settings with a command)
4. user adjustable network settings dialogs, etc..

My progress so far:

I've played with the Arduino Ethernet, and have built a rough but functional 4-channel control (actually only 3 channels at the moment). No frills there at the moment. Thinking ahead into how I can incorporate all these control features, I need to plan something solid from the beginning so I don't waste a lot of time developing one piece, only to find out it really won't be compatable with a different piece (IE TCP/IP vs. Serial).

I've been looking at Firmata for the serial side -- is it feasable to implement Firmata, as well as custom TCP/IP firmware in the same build? Is there any functionality in Firmata for TCP/IP?

Someone give me a sanity check -- am I even on the right track?

For any Arduino "professionals" out there -- this job has potential to pay for contract work, if anyone shows interest.

Any advice you may have would be greatly appreciated!!

-J

[Reply #1 on:]

I've been looking at Firmata for the serial side

My advice is DON'T!

Is there any functionality in Firmata for TCP/IP?

No. It expects data over the serial port. Period.

For any Arduino "professionals" out there -- this job has potential to pay for contract work, if anyone shows interest.

Post something in Gigs and Collaborations if/when you are serious.

[Reply #2 on:]

2. USB GUI -- user interface for serial users (also low-level setup for the controller)

I don't quite understand what you mean by these. You mean you want to plug a USB keyboard in to your controller? Or plug it into a PC USB port and configure/control it from a UI on the PC?

3. Serial command interface -- users can control the unit over serial commands rather than software

What do you mean by that?

Perhaps it would be best to produce a system block diagram showing the interfaces your controller needs to provide, and what you intend to use those interfaces. This would also be a good starting point for defining your use cases if you're serious about collaboration.

[Reply #3 on:]

Any suggestions on a better protocol to implement, or should it be something done by scratch?

A software GUI would be needed for users to adjust channel power and apply their settings to the controller -- run from a host PC installed somewhere nearby.

A serial command interface would contain a list of commands and may look  something like this:

Command: Set channel power
Format:
SC###

Where:
C = channel number
### = 0-255

Example:
S0255
S1255
S2255
S3255
etc..


This is geared towards an industrial environment with automation as a focus, where there is potentially numerous machines which are run all together through software. It is common to have software send out serial commands (rather than have a user interface). It is a vision application, so the lighting works in conjunction with camera imaging systems, sensors, etc..

 Typically used in automated inspection (inspecting beer bottles for cracks/imperfections is one example). Beer bottles may be travelling on conveyor where a camera images the bottle with a light flash or continuous lighting. Software algorithms compare defects and reject/accept the bottles as they move along.

This is just one example, but another example may be a system that must adjust intensity levels, or color settings, on the fly due to a changing product that must be inspected. This would all be automated, so a well implemented serial protocol is necessary.