Whyrl (whyrl) wrote,

NetVend overview

I'm in my thesis lab right now, and although this could be considered personal use, I see this entry as helping me to focus on my problem and prepare for next week's seminar. This is a good opportunity to try to explain my project and get feedback on what may seem confusing or areas that are incomplete.

Comments are appreciated.

NetVend's premise is fairly simple. You have a central software server that essentially controls everything. It houses the database, controls the transaction logic, displays the user interfaces through Active Server pages, and talks to vending machine controllers (VMC). The vending machines are connected to the server over the Internet or through a private network. Each vending machine has its own VMC. The controller keeps a virtual representation of its vending machine so that it knows what state it is in. A request from the software server (e.g. "VEND ITEM 34mkdst6q0") is translated by the VMC into a command that the vending machine will recognise ("VEND row5,col2"). The beauty about this system is the abstraction between the server, the VMCs and the vending machines themselves. The vending machines could dispense any vendable product, even virtual products! The vending machine could be an internet terminal, for example.

The proof-of-concept system that is gradually getting constructed is the "WEB-Enabled Electronic Component Vending Machine" or "Small Component Vending Machine" (SCVM). It is a student project that is into its fourth year. It is intended to be used in the Electrical Engineering labs to dispense electronic components to students. A student logs into a webpage and orders a component. If it is in stock, he or she is notified, otherwise the student is notified when the component becomes available (e.g. via email). The student's ID is entered into a keypad on the front of the machine, the request is sent to the server, a cost is debited from that student's account, a vend command is sent back to the machine and the component is dispensed!

Where does my project fit in? The SCVM has an embedded Linux router that controls the communication of the vending machine. The router has an Ethernet port through which it connects to the VMC, and a serial port where it communicates with an FPGA controller. The router negotiates connection with the server, handles requests from the server and the vending machine's keypad, and forwards commands to the motors, magnets, scanning and identification modules.

What is my actual aim in this project? I'm not exactly sure. :P Someone worked on the router last year but by the looks of it they didn't get very far. It didn't talk with the server, but the student rigged up a web interface and controlled the vending machine through that.

I've drawn up my own structure for the router software, which I have called the "NetVend Daemon" (NVD). I guess that's a bit misleading, come to think of it. :P I probably should rename it to "Vending Machine Daemon" (VMD). The reason I didn't choose that name initially was because I might get it confuzzled with VMC. Silly acronyms.

This is where diagrams would probably help. :b My basic program structure so far is:


SELF-DIAG : Run tests on self to check things are working.

OPEN COMM : To VMC (eth) and FPGA (serial)

: Check that the DIAG and COMM functions succeeded
- NO : Report errors
- YES : Enter into NORMAL operation

CLOSE COMM : Shut down communication - would not normally reach here.


(NORMAL) : Normal operation - need a better name for this function!
↑(VMC_IN) : Non-blocking check for messages from the VMC
↑ ↓
↑(SLAVE_IN) : Non-blocking check for messages from slave devices (i.e. FPGA)

Loops until an error condition is reached. Yes, I'm using polling, but I don't know enough about using interrupts (a) under a new platform, i.e. ucLinux, and (b) on the Coldfire chip. Plus I'd like this code to be as portable as possible.

Heh. I've spent an hour on this to get this far. :P

When a message is received, it is sent to the command interpreter for that channel (i.e. upstream or downstream communication). The interpreter parses the command to determines its type, then calls the function for that specific command.

Example: Command from the VMC is "VEND 5,2". This is sent to the VMC interpreter. It parses the first argument of the command and determines it is a "VEND" instruction. The vend function is called with the arguments to the vend command, i.e. vend("5,2");

At this point I'm not entirely sure what to do. I was thinking that the commands could be scripts, somehow.

// Begin pseudocode
int vend (*char msg) {
   int row, col;
   sscanf(*msg, "%i,%i", row, col);
   slave_out(MOTOR_CMD, row);  // send command to FPGA
   chk = slave_in();           // receive response code
   if (chk != OK) {
   slave_out(EM_CMD, col);
   chk = slave_in();           // receive response code
   if (chk != OK) {

Something like that, anyway. I was reminded that Skan wanted a C-like scripting language for DSP work (and have it named "RavenScript"). Wishful thinking told me I could write RavenScript for this project. :D

Anyway, the point of having scripts was so that changes could be made to the communication protocol without having to recompile the daemon. I've got no idea how to do that in C, though. Specifically, how to call a module from within another process, assuming the module is compiled. If it's a script then I'd have to write an interpreter. I guess this is something I should ask my supervisor.

That's where I'm at with my project right now. Yes, still in the design stage. :P I probably should get back to it.
  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment