2D plotter project

[+Vorticon]

https://youtu.be/C4LmvPvJ2Ww

 

 

Details in blog: http://atariage.com/forums/blog/659/entry-14733-x-y-plotter-table-for-the-ti-994a-computer-final/

[+Vorticon]

Albert love... Using The Missing Link for image loading and processing from XB.

 

 

[jdgabbard]

This is so cool.

[sparkdrummer]

It goes without saying how I feel about that image.

[Tursi]

Albert love... Using The Missing Link for image loading and processing from XB.

 

AEN plotted.jpg

 

 

Hah, nice! How long did that take to plot?

[+Vorticon]

 

Hah, nice! How long did that take to plot?

1.5 hours... Did I mention it was slooooow? This is particularly evident when printing an image like the Albert one because all 51200 pixels of the bitmap screen have to be checked for on/off sequentially. It's not as bad a problem when plotting mathematical drawings where only the calculated pixels are plotted as seen in the video.

[Tursi]

Slow, but it looks good! Your next challenge is to get the two axes stepping together

 

I'm pretty jealous. It's an awesome toy!

[+Vorticon]

Slow, but it looks good! Your next challenge is to get the two axes stepping together

 

 

That's actually not very hard to do: just add 8 lookup tables of motor activation sequences for the 8 possible cardinal directions of movement since both the X and Y axes are actually controlled by the same 74HC595 chip. It would involve a bunch of IF/THEN statements in XB (where is the CASE statement when you need one...) which would slow things down further, but then this could be offset by the faster travel of the pen.

That said, it would not help for plotting a full bitmap image because all the pixels are getting tested in a sequential fashion, so the print head is only moving down one pixel for each 256 horizontal pixels... Most of the benefits would be for drawing calculated images.

Something to hammer out at the pre-Chicago Faire jam session Which reminded me of how you helped me set up on the fly a short demo of the robotic arm using the Mini Memory module a few years back when I had forgotten the driver disk at home! Good times

[Tursi]

Oh! The motion is determined on the XB side? In that case I'm pretty impressed how fast it runs!

 

Yeah, I'm sorry I won't be there. :/ I really wanted to support the extra day concept this year. Hope for lots of pics and stories!

[+Vorticon]

Oh! The motion is determined on the XB side? In that case I'm pretty impressed how fast it runs!

 

Yeah, I'm sorry I won't be there. :/ I really wanted to support the extra day concept this year. Hope for lots of pics and stories!

XB calculates the pixel plot positions then issues the appropriate assembly subroutine calls that move the axes in the desired direction via a series of FOR/NEXT loops.

Hopefully you can attend next year

[HOME AUTOMATION]

I believe congratulations are in order! :)

 

I have been following your work on this project with a renewed interest after learning that you are using 595 shift registers in the driving of motor coils. I have been considering upgrading my home automation controller using shift registers, initial tests have been hampered by electrical noise issues. The 595's I'm using seem difficult to isolate from the cemf of so many relay coils. I couldn't help but notice that your system seems to have achieved stable operation... without any obvious remedies in place for noise. I've wondered if the 1N5822's carry drive current or suppress transients. I speculate your 595's CLK,LATCH,DATA are isolated from the TI's noise by bus drivers in the parallel port circuitry? It appears that your design is powered by the PEB's power supply. I have suspected my design may be hampered by being powered from the CONSOLE or because the 595's CLK,LATCH,DATA are driven directly by the 9901's I\O PORTS.

I am curious what make model 595's your using, I can't make the #s out in the pics they look like TIs'?

[+Vorticon]

I believe congratulations are in order! :)

 

I have been following your work on this project with a renewed interest after learning that you are using 595 shift registers in the driving of motor coils. I have been considering upgrading my home automation controller using shift registers, initial tests have been hampered by electrical noise issues. The 595's I'm using seem difficult to isolate from the cemf of so many relay coils. I couldn't help but notice that your system seems to have achieved stable operation... without any obvious remedies in place for noise. I've wondered if the 1N5822's carry drive current or suppress transients. I speculate your 595's CLK,LATCH,DATA are isolated from the TI's noise by bus drivers in the parallel port circuitry? It appears that your design is powered by the PEB's power supply. I have suspected my design may be hampered by being powered from the CONSOLE or because the 595's CLK,LATCH,DATA are driven directly by the 9901's I\O PORTS.

 

I am curious what make model 595's your using, I can't make the #s out in the pics they look like TIs'?

 

Thank you

The main reason to use the 595 was to reduce the number of control lines needed to run the motors. As things stand, I only need 2 main lines for all and 1 additional for each couple of motors. So in theory I can control a total of 12 motors with only 6 595 chips using the 8-bit parallel port! Very useful chip indeed... Here's a picture of the ones I ordered off of Ebay - Chinese supplier:

 

 

The controller board uses the PIO +5V line for logic power to the 595's, but has a separate 5.5V 1.5A supply to drive the L298 dual H-bridge chips and stepper motors. The diodes are mainly there to protect the circuit and the PEB from the high current spikes induced by the stepper motor coils and are not connected to the 595's control and data lines. While testing the board using a logic analyzer, I did not detect any errand spikes or such and have had no issues with noise on the operational level. It is very likely that the parallel port circuitry has something to do with it as you mentioned.

 

During the testing of my TI Vision hack a few years back, I experienced a lot of extraneous noise in the circuit connected to the PIO port, and it turned out that this was due to the rat nest of wires on the breadboard during the prototyping process. It got resolved once I moved the design to a proper PCB.