Human Interface for firmware: Buttons and displays.

There does not really seem to be a place on the other thread for some Ideas I am considering. I thought I would make a separate thread to discuss some of the following ideas relating to buttons and displays that would access data sets either generated on the host or stored on the device.

1) Storage. Given the current popularity with SD/MMC and the simple SPI protocol, it seems that there should be an option for direct download and buffering of the data onto the memory stick.

This may not be completely future proof. About 8 years ago I implemented Compact flash reading on AVR. This was the at90S8515 which had the same pinout as the then popular intel8051. The CF card was memory mapped.

The first cards were FAT12. Then FAT16, Now FAT32. While in Fry's over the weekend I did not see any Compact flash cards less than 2GB.

SD/MMC is pretty much the same, My test cards are 32MB, 512MB and 8GB.

Ideally a firmware controller would entail usb "On-the-go." this way one could read simple USB memory sticks. Sadly there is lacking a device like the FTDI modem bride that will interface with the 8 bit AVRs currently used.

One could implement firmware on the USB enabled AVRS such as the AT90USB127. These even come from ATMEL preloaded with the FLIP bootloader. For most users this would require porting Arduino libraries. There was some discussion of this on the Arduino forums. Not sure what has been done since I am an assembly programmer.

Personally I feel that some sort of removable memory device is the best place to buffer the incoming data.

2) User experience. I see this as smart and dumb terminals.

First explination, a dumb terminal. With the simple NC machine model, one has a tool, which is connected to a DRO (Digital readout device.) This would be a LED type display showing the states of the counter registers. Simple lights indicate fault conditions.

The user interacts with the tool using a joystick. The joystick could be simply buttons mounted on a box. Typically buttons to move the axis. On a simple NC machine, there are buttons for home position and tool change position. Feedrates and spindle speeds are set by dials. The axis are moved by holding down the joystick button and rotating the feedrate dial fast or slow.

An easy to use joystick could be as simple as a DVD remote, with menu selection arrows and an IR link. A simple Joystick/button panel, would connect to the RS232 input port, bypassing the USB Bridge. The Joystick could also use one of the I2C or other internal comm channels.


Smart terminals An interactive display running a complex solid modeling package. For subtractive machines, this may be a program like EMC2/Mach3/KCam4. These controllers bit bang the I/O and return realtime states of the tool. In this cases the firmware is fairly dumb, or not even existent.

It is possible to create firmware that responds to both smart and dumb terminals. This is representative of what we currently have. This is still an NC interpreter. The axis controllers are bit twiddled to operate. These respond to enable/Step/Direction bits.

Using the Gcode model, we have an input stream to the device. This has been extended to allow some of the modal commands to return data to the host. Typically a ready state, when the temperature is valid and the tool in home position.

The user experience I envision is that the host creates the tool paths. These are then saved on memory stick devices, or downloaded to the tool firmware.

The tool firmware could act immediately on the Gcode. It should also be possible to save the tool path to the memory stick.

Returning to the PostScript printer model. Normally the interpreter runs in a loop, waiting for a job. The job ends when there is a timeout or when an EOX (control-D) character is received. there is an operator called eexec, which causes the job loop to terminate. In effect the interpreter is in root mode. This allows program access to read and write system states.

Currently the Gcode firmware does not have the equivelent of eexec. There are no file or library commands other than some instances to execute pre-determined sequences. There are some provisions for subroutine cycles, using jump and monitor modal commands.

3) Implementations & future directions.

From the suggestion in the packet thread it should be practical to use either a smart or dumb terminal to communicate with the firmware. Some sort of file system would be needed.

With Musical Instrument Digital Interface [MIDI] devices, there is the concept of filers. This is a subclass of sequencers. Typically a MIDI filer consists of buttons to start and stop the media as well as some sort of interface to select which file to either play or record to. A variation of the MIDI filer for wave audio is an MP3 player best exampled as an iPod.

For the reprap, there would need to be some definition and minimal file selection system. Not unlike the services provide by DOS. Most likely the data will be stored in FAT32 directory sectors. This may not hold in the future, if NTFS or a Unix directory system becomes standard ways to access large data sets.

For the near term, the firmware will be controlled by FAT32 directories and Gcode data sets.

I would propose that the commands to access the files on the memory card be some sort of unix like, rather than DOS. These would be ls for a list of files, cd for change directory. rm for delete and so forth. Directory hierarchy would be notated with unix style '/' delimiters even if the file system is FAT32.

The firmware would wake up in File mode. It might be advisable to add some switch straps, which could wake the firmware in gcode only mode. The terminal could then send commands to indicate if it is a smart or dumb terminal.

If only a DRO display is desired for feedback, this might not even communicate through the serial line. The same could be observed for joystick control. The joystick buttons, would select with file from the cart to make into a part. The DRO would indicate which file is selected.

I am unclear as to how to switch from file mode to gcode mode. There would need to be a distinction between save to memory stick, or make the part. The choices are between the PostScript job loop or a unix like command line. Another alternative would be to implement Mcodes to act as a file system within a Gcode program, I think this latter idea lacks merit. especially if more than one NC or solid model is used within the system.

What happens to the main serial line while the part is made from a dumb terminal. It may make sense to retain the existing modem simulation as suggested in the Packet thread. In this case the smart host (with GUI solid modeling display) monitors the com channel. This GUI is also a Gcode interpreter. As the Block is processed by the firmware, the ASCII characters are sent to the host, the same way they are echoed. After the newline or as idle packets the device can return the states of the NC counter registers. The host could either simulate a DRO (like EMC2/Mach3) or it could actually display that part of the model in a 3d world. Either as toolpath or a virtual 3D construct.

The host would also have the capability of emulating a joystick button panel. This way a simple host could consist of a part selector, DRO and Joystick. All which could be implemented in python or Java.

A design host would generate the part data (here stated to be Gcode) This would be some sort of solid modeling and slicing, similar to the Skienforge approach.

4) addenda and notes.
While I have considered some issues such as floating point to NC register count conversions, I have left this out intentionally. Inside the firmware registers, shout be nothing more than counts stored in native units. Preferably some sort of fixed point.

I have also intentionally left out some of the tool description, such as extruder with and speed. These are not unlike the tool diameter and spindle speed. The relation here is more like the Gerber extensions which are used to draw traces and pads.


-julie

Julie

First and foremost you are a star, and have clearly been around long enough to absorb a disproportionate amount of corporate new clothes.

Hey the emperor bought it, why shouldn't everyone else.... right...

But actually as engineers having to deliver the rubbish that marketing folk set the punter up for. we knew it was imaginary clothes before the boy in the street who didn't know not to say, said it.

God bless kids they say what they see and it is always truthful (awkward, painful, but ultimately always truthful, no guile, I love them for this if nothing else). I have some of my own.

You are clearly clever, clearly skilled, have clearly seen a bunch of what is going down.

Stop with the corporate product double talk and lay on us what you can contribute.

On HCI you are right, the RepRap machinery has'nt got any, we know this.

What can you contribute ????

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I managed to create an account on Git.

The usual problem persists. No support for OSX PPC Tiger. This is getting ridiculous. Talk about corporate empires.

I also had the usual luck with Skienforge, again, too much dependency on revisionism and minimum version requirements.

This is why there are 100s of implementations of the software, because no one on the host side can resist not having the latest libraries and bloatware features. Too much make work, writing little scripts and measurable tools, so management feels that they are getting value for hours spent.

At least I can write firmware in assembly, that responds to button presses and can read media cards. --That-- is what I can contribute.

Some progress update, I have stripped the MIDI parser from my app and am ready to implement the G-code parser.

The existing hardware has an LCD display, with 40 chars, this can be used as a DRO. It also has a button board for selecting which MIDI file to play. The current HW uses compact flash, I am working to convert this to use SD/MMC. The end result should be able to run on an Arduino.

-julie



-julie

Excellent

It might be worth you taking a quick peak at :-

[dev.forums.reprap.org]

There is a move towards an IO backplane based experimental model, with plugin cards for different things, to allow everyone to do their own thing but still work (sort of) together.

I am just completing board design for the backplane, but have already posted a PDF of the schematic giving the pinout.

Don't know if this would be useful for you at this point or more of a hinderance.

Cheers

aka47

PS is the LCD one of the ones based on the usual Hitachi controler chip ?? (2 by 40 or some such), How many keys are you looking at ??

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I have been following that thread too. A bit undecided about that structure.

Adding end-stops to the CNC and the layout of Mendel, to me make more sense routing a network cable. I like the idea of distributed processors.

Yes standard Hitachi controller 2x40. I bought a case of these 7 or 8 years back.

Not sure what you mean by keys. If you mean how many wires used on the larger AVRs, like the mega162 I memory map these so it is just a peripheral on the bus. With the mega88, I bang them in 4 bit mode.

If you mean jog buttons, This is a 4x4 matrix. Currently Mapped for music playback, A star aray of buttons like a DVD remote for up/down left/right with enter in the center. Normal music play buttons across the bottom for play pause stop.

File selection from the card is done with the selection buttons. If the selection is a directory, Enter is used for setup menus.

When a card is inserted, the first name on the disk is shown. The arrows are used to navigate through the directory tree. I also have an option for IR remote. Using a cheap radio shack replacement TV controller.

-julie

... last week i bought some digital jogwheel-encoders, miniatur-joysticks and motor-potis from a German ebay-shop - look here for types and prices in Euro.

The digital encoders were around 50 cents, the mini-joysticks around 2 Euros and the motor-potis at 5 Euros each.

I'm building another application with them, but should be interesting for reprap too ...

Viktor

Yep by keys I usually mean press buttons or the things on a key pad. (however, shaped or arranged)

I guess these are what you are thinking of as jog buttons.

The bits that a user presses to tell the machinery what they want.

I have a pile of the LCD displays kicking about in a junk box too. I recovered them from a whole box of regfrigeration controls that had been scrapped. I have used these in instrumentation and terminals a few times.

Out of interest are you driving them in 4bit or 8 bit mode ??

Must agree as a transputer fan I prefer distributed processors. It scales well and gives easy true concurency.

The original design for the electronics was a serial buss (actualy a ring) with processors dedicated to tasks around the machine. I liked this idea very much as it was modular.

The electronic design work that followed was principally driven by designers that had a commercial interest, naturally this lead towards a single board design. For reasons of production costing. But its integrated non modular approach pretty much rules out experimentation.

The commercial designers now have their product and kit/s.

You might notice that there is an RS485 buss along the backplane. This would be a useful start point for some designers to prototype a newer serial bus design that would lend itself to being pulled apart and distributed.

The backplane and plug-in cards is arguably one way to break apart the currently integrated design and make it easier for folk to prototype what they want. Facilitating the new without completely binning off the old.

Looking forward to seeing some of the work you are doing, it sounds fun.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I posted to GITHUB the initial lash-up of my code. The name of the project is HIDAVRGcode. The public user name is sheepdoll.

This code was based on a project that started with a target cpu of AT90S8515, which is the same footprint as an 8051, but runs the AVR instructions. The code originally read floppy disks through DMA to an off chip sram buffer. The code still relies on software multiply as the AT90S8515 did not have a MUL instruction.

Changes were made to connect to Compact flash card sockets. This requires external memory support. The mega88 and mega168 do not have enough pins for external memory. It should be possible to replace the low level CF reads with SD card serial reads. The SD card init code has been added, The low level block commands have yet to be written.

The goal of this project is to keep the code size small and fast. Easy to port to the hardware I have at hand. Most AVR instructions map to C language primitives, I have been programming in assembly for over 10 years, so I find it easier to use than figting library revisionism, where libs are changed for the sake of changing libs. With assembly nothing is obfuscated.

Much use is made of the timers and interrupts. The midi code was designed to work with a fixed clock interrupt and counter register. This is not unlike how a stepper drawing system works. More on this later. There is much written in the micro-controller forums on this subject.

The units for conversion used is a form of fixed point numbers. The integer part is signed 8 bit. This does limit the scale of the system to a maximum travel of 128 units. This may not be enough for metric. As most workspaces are less than 10 inches, this should not be much of an issue when inches are used.

The fractions are stored in a normalized 16 bit format. This is in effect a multiply of 10000. Much work needs to be done to map this to the system used for drawing lines.

The main change to the code, was to add a G-code parser. There are many types of G-code files on my computers, so the desire is to have a parser which can handle these files without having to edit them. Currenlty only the skeleton is written, which handles the eol and whitespace removal. Some of the common codes save the register numbers in a fixed place. These will eventually go into a circular queue.

Mostly this code was posted to test the GITHUB repository.

-julie

I have the basics on my controller v1.2 assembled. I posted to the thread I started in the electronics forum with the link to the blog post.

The changes I made to the old MIDI FAT firmware, ported over without much issue to the actual mega644. I had to adjust some of the sram parameters for the larger memory. There were also some complaints regarding the USART names as the 644 has two USARTS

Now that I have constructed some actual hardware, I have a better feel as to how this pins are being used to drive the steppers.

Currently since the SD card is on port B, I have no pins for the button panel. At best I could implement the IR remote, however that wants an interrupt pin, which has a specific function.

It is easy to be a critic, and this board and choice of pin usage leaves a bit to be desired. I guess this comes from the high level abstraction provided by the Arduino sketches. It took reading both the code and the schematic to locate the actual pins used. In practice the step pulses should be on the PWM output pins.

The more I think about it the more I like the idea of using coms to handle the stepper control. The most practical would be the tiny25 as I have a bunch of these chips. There are not enough pins on the '25 to control the motor and I2C. There are enough to handle I2C and the step/dir/enable signals. A separate controller would be needed for the limit switches.

This would free up lots of I/O pins for buttons and displays. If the display was handled by the TWI also, then one could probably run the code on a 16K arduino, possibly even an 8K one.

The way I am coding the stepper system to work, is through a master clock and fixed point math. This comes from some examples suggested on the avr forums.

The timer counts in fixed point steps. Currently I have 24 bit registers with 16 bits of fraction. This is decimal shifted to normalize the fraction inside the 16 bits. All one has to do is increment the master register by a step amount. The 16 bits overflow at one inch of travel. (Metric systems can use 1CM) Each tick of the clock represents the movement for one step at the current feedrate.

It is easy enough to capture the step rate overflow and output the pulse based on the DDA. Since the TWI devices are always listening for an address match, it is easy to send a simple step now message on the bus, If the address bits are simply a mask for step and direction then the motor driver sets the pins and pulses the step if needed.

The nice thing about this method, is if the output display uses the same address as the axis, It can simply display the expected position using the same sort of fractional register. The main controller could also query the axis controller and get the estimated location and test for errors in the counter.



-julie

you may wish to read [www.embedded.com] which shows you how to do constant acceleration without a master clock. I have implemented this in my firmware if you'd like an example.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

That looks a lot like this tutorial from the AVR forum. I was thinking of playing about with this once I have some of my hardware working.

I built one of the stepper v1.2 LM298 board I got last year. I also found some nice NEMA23 motors which only require 1 Amp at 3 volts, so have something smaller than the coffee cans to experiment with. Also found a NEMA17 from a scanner in the spares box. The nema17 is 5 wire which makes it awkward for bipolar. I did locate some MFG pages on the nema17 although this was a custom motor and there is not a direct part number match.

Sometime I would like to see your firmware? Is it real C or an arduino sketch. Most of my work is in asm, which on the AVR is quite similar to C anyway. I like keeping things simple and where I can see everything.

-julie

my firmware is real C. I've never even seen the arduino software, just avr-gcc, avr-libc, avrdude, my favourite editor (kate) and gnu make. my firmware is available from github, grab the link from my other posts about it.

I learnt C by doing largeish projects in assembly. C simply didn't make sense to me until I understood the underlying methods and the shortcuts that it represented. Now I have the ability to check the resultant assembly and alter my C code until I'm happy with the translation.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

i would like to see a display added to the reprap, even just for debugging information. but i hope to add some buttons to my unit, so that i can manually move my print head

---

[mike-mack.blogspot.com]

dissidence, hd44780-based LCDs are very easy to drive, as are nokia 3210/3310 LCDs. I think the latter take SPI commands.

As for manually moving things, I recommend quadrature encoders, such as those found in ball mice. When I was starting my electronics, I used one and it worked really well

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

hd44780 is what I use a lot, The main issue is that these things eat pins, At least 7 pins are needed, which is most of a port.

When the processor supports external memory, I like to memory map the LCD, this way reads and writes are DMA mapped, which is useful for debugging.

One of the first Atmel projects I worked on was to interface one of these units in 4 bit mode. While 8 bits seems easier, The access to the chip needs to be on 2 ports. Either way 2 reads or writes is needed for access to update the display.

As for manually moving things, I think dissidence is wanting to move the motors with jog buttons, Which is one of the features I want.

I must say that the quadrature encoders is an interesting idea. Simple and effective. That way one would just have to crank the handles on the rep-strap instead of using the jog controls. The only downside to that is when the motors are inactive they become little generators,

I have been working on cleaning up some old MIDI boards, which have a buttons and a display. I am changing these to work with SD cards instead of floppy disks. Attached inline is a photograph of the old development system I resurrected.



The button array can be clearly seen in the center of the photograph below the hd44780 display. What would be considered as the repstrap motherboard is underneath the ICE200 pod. The electronics to the right connected to my USB RS232 converter is the ICE200. The SD socket lash-up is in the lower left.

The JTAG ICE is not in use with this setup. The chip under test is an older At90S8515. This chip and the mega162 chip have the same pinout as the popular i8501 and support external memory. In Arduino terms this would be the same as a mega8 chip with more pins.

I have a dozen or so of these boards, which I want to clean up and use either as MIDI players or possibly repstrap mother boards. To Buffer the MIDI, there is 128K of external sram, which makes reading files really easy as one can read in large buffers from the disk.

The downside to use this as a mother board is that there is only 8K of code space. To fit any practical code into this space, one pretty much needs to code in assembler. I did post an early version of this to github. If there is interest I can post an update, which can read either FAT16 or FAT32 files.

The LCD and xmem also take up all the IO pins, What I/O pins are left the button board takes up. There are no extra lines for debug LEDs.

A separate controller would be needed, This would communicate through the normal serial I/O lines.

The button I/O board in effect replaces the host. This in effect is sort of the opposite of the EMC2 approach where the host directly drives the motors. What A dedicated I/O controller offers is more of a file storage system. Where the files are transferred to the memory cards.

There is still much to consider in the way of the Interface direction and work flow. If a small dedicated box with buttons and display is preferable to an application which models the part and also controls the toolpaths. This was the original host Java approach.

In practice, the Skienforge/etc splits the work flow into a series of steps, where the design phase is alienated from the toolpath creation phase. Both of which are done in the host. The firmware then becomes and afterthought.

-julie