Hacking the HP45
-
- Posts: 116
- Joined: Sat Aug 25, 2018 5:26 pm
- Location: Poland
Re: Hacking the HP45
how much ampere does hp45 use when working
- dragonator
- Site Admin
- Posts: 597
- Joined: Fri Aug 14, 2015 4:48 pm
- Location: The Nethelands
- Contact:
Re: Hacking the HP45
It draws peaks of around 4.5A at 12V, but on average it should be 1-2A. The duty cycle on the scale of milliseconds is lower than 50%, probably 10%-20%.
- dragonator
- Site Admin
- Posts: 597
- Joined: Fri Aug 14, 2015 4:48 pm
- Location: The Nethelands
- Contact:
Re: Hacking the HP45
I have been somewhat busy this vacation getting DMA to work. I am not at a point that I have all of it working in principle, all I need to do now is test it with an actual printhead.
I have not said much about it here, but I am busy getting DMA to work for the inkjet printhead. Right now I need around 220 microseconds for one full burst, and due to the incredibly timing critical nature of inkjet, I could not do anything during that time. DMA can perform simple tasks directly from RAM, without the CPU doing anything with it. The idea is to wire up 2 ports (port C and port D) to the address next, primitive clock (tied to primitive clear which is active low) and all primitive pins to these ports. I load the right pattern I need to inkjet into RAM memory, and trigger it with DMA. I can then do other things while the printhead is busy printing.
I would not be able to do this myself, but luckily, Teensy has a lot of stuff built in, and one of these things is the OctoWS2811 library (https://www.pjrc.com/teensy/td_libs_OctoWS2811.html) that can set 8 strips of addressable leds at the same time without any processor involvement (using DMA). The library does some things that I do not need as well, but most importantly it sets a whole port based on what is in the RAM memory. This is the part that I need, and modified so it also does it to another port.
It took some effort. There are some mysterious issues, mostly that I cannot trigger both ports at the same time and need a 100ns offset between the two. I now have it working. Below the logic analyzer images of the 2 full ports. They look just like they do right now, with the only difference being that this is done over DMA.
First a cascade where I trigger each primitive individually. There are 3 clocks per address to keep the inkjet stable. This is an old workaround that is still being used.
Triggering all primitives. The top row is primitive clocks, the second row is address next pulses. All other rows are primitive signals.
A closeup on one pulse showing the offset between the 2 ports.
I hope I can test the inkjet before my vacation is over. otherwise it might take a week more. Once the DMA is tested I will build it into Oasis and test it. I will then also add some functions to the firmware of the printhead driver that make it more useful for general purpose ink jetting.
I have not said much about it here, but I am busy getting DMA to work for the inkjet printhead. Right now I need around 220 microseconds for one full burst, and due to the incredibly timing critical nature of inkjet, I could not do anything during that time. DMA can perform simple tasks directly from RAM, without the CPU doing anything with it. The idea is to wire up 2 ports (port C and port D) to the address next, primitive clock (tied to primitive clear which is active low) and all primitive pins to these ports. I load the right pattern I need to inkjet into RAM memory, and trigger it with DMA. I can then do other things while the printhead is busy printing.
I would not be able to do this myself, but luckily, Teensy has a lot of stuff built in, and one of these things is the OctoWS2811 library (https://www.pjrc.com/teensy/td_libs_OctoWS2811.html) that can set 8 strips of addressable leds at the same time without any processor involvement (using DMA). The library does some things that I do not need as well, but most importantly it sets a whole port based on what is in the RAM memory. This is the part that I need, and modified so it also does it to another port.
It took some effort. There are some mysterious issues, mostly that I cannot trigger both ports at the same time and need a 100ns offset between the two. I now have it working. Below the logic analyzer images of the 2 full ports. They look just like they do right now, with the only difference being that this is done over DMA.
First a cascade where I trigger each primitive individually. There are 3 clocks per address to keep the inkjet stable. This is an old workaround that is still being used.
Triggering all primitives. The top row is primitive clocks, the second row is address next pulses. All other rows are primitive signals.
A closeup on one pulse showing the offset between the 2 ports.
I hope I can test the inkjet before my vacation is over. otherwise it might take a week more. Once the DMA is tested I will build it into Oasis and test it. I will then also add some functions to the firmware of the printhead driver that make it more useful for general purpose ink jetting.
- Attachments
-
- HP45 standalone Samples complete.PNG (70.27 KiB) Viewed 18172 times
-
- HP45 standalone cascade 1-22.PNG (22.61 KiB) Viewed 18172 times
Re: Hacking the HP45
DMA can be difficult to get right, but I definitely think it's the right direction. Theoretically, if you built a board from the ground up, you could use DMA to control the stepper motors and the inkjet head based on the same timer so that everything would be perfectly synchronized.
- dragonator
- Site Admin
- Posts: 597
- Joined: Fri Aug 14, 2015 4:48 pm
- Location: The Nethelands
- Contact:
Re: Hacking the HP45
Oasis runs 2 different controllers. One is arduino Uno based and drives all the motion. The other is the standalone inkjet controller. The inkjet controller takes it's position from an encoder on the gantry. I cannot use DMA to also control the steppers because they are not attached. If they did it would certainly be an option, though controlling motors through interrupts should also be a decent option.
Re: Hacking the HP45
The other option is that you can use DMA on the motion controller and have it send out a sort of clock signal to the inkjet controller to perfectly synchronize the two.
This may, however, be based on a lack of understanding on how you'e synchronizing them now. Do you mind going into a little bit more detail on that?
This may, however, be based on a lack of understanding on how you'e synchronizing them now. Do you mind going into a little bit more detail on that?
- dragonator
- Site Admin
- Posts: 597
- Joined: Fri Aug 14, 2015 4:48 pm
- Location: The Nethelands
- Contact:
Re: Hacking the HP45
Oasis runs 2 controllers. One is motion, controlling the full gantry, spreader, and pistons. The other is the inkjet driver, controlling the printhead. It is separated because writing motion drivers sucks, and having 2 timing critical, complicated things run on the same controller in the past has proven more trouble than it is worth. Both controllers are driven by the same software over usb (and indirectly a form of serial, though teensy's are a bit odd here).
The motion controller is an Arduino Uno running GRBL. It has 4 motors attached to it: X, Y, Feed and Build, all with their respective endstops. The spreader motor is also attached to one of the output pins of the GRBL. On the Y axis is a 150 lines per inch encoder tape.
The HP45 standalone driver has a Teensy 3.2 and is running my own firmware. It has the HP45 printhead and an encoder tape reader attached. The encoder is used to synchronize the position of the GRBL motion to the inkjet. All inkjet print commands are given with a position.
With this setup I do not have to write complicated motion drivers, or take existing motion drivers that will give problems implementing because I have other timing critical stuff. I simple send a Gcode command to the motion driver, and the inkjet data to the inkjet driver. After that they work out themselves what happens next. It works surprisingly well.
The motion controller is an Arduino Uno running GRBL. It has 4 motors attached to it: X, Y, Feed and Build, all with their respective endstops. The spreader motor is also attached to one of the output pins of the GRBL. On the Y axis is a 150 lines per inch encoder tape.
The HP45 standalone driver has a Teensy 3.2 and is running my own firmware. It has the HP45 printhead and an encoder tape reader attached. The encoder is used to synchronize the position of the GRBL motion to the inkjet. All inkjet print commands are given with a position.
With this setup I do not have to write complicated motion drivers, or take existing motion drivers that will give problems implementing because I have other timing critical stuff. I simple send a Gcode command to the motion driver, and the inkjet data to the inkjet driver. After that they work out themselves what happens next. It works surprisingly well.
- dragonator
- Site Admin
- Posts: 597
- Joined: Fri Aug 14, 2015 4:48 pm
- Location: The Nethelands
- Contact:
Re: Hacking the HP45
DMA update. Late due to procrastination and a mystery problem that is now identified.
Short recap of what I want to do. I want to trigger the inkjet over DMA. I wrote a DMA driver that worked for 2 full ports. I now have 2 DMA ports that can produce a parallel signal at over 1MHz. I load the pattern in RAM, and trigger the DMA when I need it. I have 17 pins that are needed during a burst. A primitive clock, a primitive clear (That is active low), an address clock pulse and 14 primitive data lines. I made a custom controller board to test the new required setup. I attached the primitive clock and the primitive clear together. When the clear is low, everything is cleared, and when the clock is high, the latch is triggered and all activated digital pins become high. This way I can fit everything on 2 ports of 8 pins each.
I tested this for a few days and it simply would not work. All the individual pins worked fine, timing seems fine, it makes it to the driver board, but it simply does not make the primitive drivers high. An old driver with the same type of firmware loaded does trigger all nozzles. Something is going wrong. On the DMA circuit the only difference is that the primitive clear and clock are connected.
One trip to the TLC59213 datasheet gave the answer. The clear signal can be high or low to get it's effect, but the latch is only triggered on the rising edge of the primitive clock pin. The difference can be tiny, only 50ns, but there has to be a difference. I trigger both at exactly the same time. This leaves me with 4 potential fixes for the problem:
I will be making a test circuit this weekend trying to make it work with a 555 timer. Updates when I have progress.
Short recap of what I want to do. I want to trigger the inkjet over DMA. I wrote a DMA driver that worked for 2 full ports. I now have 2 DMA ports that can produce a parallel signal at over 1MHz. I load the pattern in RAM, and trigger the DMA when I need it. I have 17 pins that are needed during a burst. A primitive clock, a primitive clear (That is active low), an address clock pulse and 14 primitive data lines. I made a custom controller board to test the new required setup. I attached the primitive clock and the primitive clear together. When the clear is low, everything is cleared, and when the clock is high, the latch is triggered and all activated digital pins become high. This way I can fit everything on 2 ports of 8 pins each.
I tested this for a few days and it simply would not work. All the individual pins worked fine, timing seems fine, it makes it to the driver board, but it simply does not make the primitive drivers high. An old driver with the same type of firmware loaded does trigger all nozzles. Something is going wrong. On the DMA circuit the only difference is that the primitive clear and clock are connected.
One trip to the TLC59213 datasheet gave the answer. The clear signal can be high or low to get it's effect, but the latch is only triggered on the rising edge of the primitive clock pin. The difference can be tiny, only 50ns, but there has to be a difference. I trigger both at exactly the same time. This leaves me with 4 potential fixes for the problem:
- Delay the clock pin with a capacitor and a resistor so it lags around 100ns behind the clear pin. This means that the clock timing is less defined, but it takes few components.
- Put the clear low signal on a one shot timer. When the clock becomes low (falling edge), a one shot timer with a 555 makes the clear low for a few hundred nanoseconds. This clears the output of the primitive drivers. It then becomes high again, so that when the clock becomes high, it can latch the data.
- Put both clock and clear on their own pins, and make the address next signal trigger with a combination of primitive data lines through an and gate. Right now I pulse the primitives in 3 stages. If I trigger all at once, the ink flow becomes unstable. If I ever figure out what is going wrong here, I am back at square one.
- Give both TLC drivers their own clock pin, and share data and clear. This way I reduce the current 16 pins needed to 7 data pins, 2 clocks, 1 clear, 1 address clock, or 11 in total. This way I will always need to fire in at least 2 stages, and maybe 4 stages, but I get more data pins on the Teensy available (and I am running low). It also requires a driver modification, which I am hesitant to do. Right now I only need to update the controller.
I will be making a test circuit this weekend trying to make it work with a 555 timer. Updates when I have progress.
- dragonator
- Site Admin
- Posts: 597
- Joined: Fri Aug 14, 2015 4:48 pm
- Location: The Nethelands
- Contact:
Re: Hacking the HP45
A 555 does not work. While all examples on the internet speak of a 555 being rising edge triggered, it is not. It is can extend a pulse, but not make a shorter pulse than the input.
This left me with the issue of what to use. I bought 74HC123 monostable multivibrators. On the breadboard it worked fine. I made a tiny board in the wiring to test it on a working printhead.
I can now print with DMA. I cannot validate that I get the 200-500ns pulse on the clear, since my tiny scope at home does not measure past 1us, but when I am at the local hackerspace, I will test the signal on the logic analyzer or scope. When I had the capacitors for 5us and 50us it worked fine, so I will assume it works. The assumed signal looks like this right now.
P clear is the output from the 74HC123.
I will continue tests with DMA and see if I can get it to print on Oasis itself. When that works, I will add some of the functions I have wanted to add for a while now, such as virtual speed, text to buffer and hardware triggers. This should make the inkjet controller more usable in more cases.
This left me with the issue of what to use. I bought 74HC123 monostable multivibrators. On the breadboard it worked fine. I made a tiny board in the wiring to test it on a working printhead.
I can now print with DMA. I cannot validate that I get the 200-500ns pulse on the clear, since my tiny scope at home does not measure past 1us, but when I am at the local hackerspace, I will test the signal on the logic analyzer or scope. When I had the capacitors for 5us and 50us it worked fine, so I will assume it works. The assumed signal looks like this right now.
P clear is the output from the 74HC123.
I will continue tests with DMA and see if I can get it to print on Oasis itself. When that works, I will add some of the functions I have wanted to add for a while now, such as virtual speed, text to buffer and hardware triggers. This should make the inkjet controller more usable in more cases.
Re: Hacking the HP45
Hi Sean,
Could you share information where to buy those things? I look for it to develop a printer using FPGA based hardware.
![Smile :)](./images/smilies/icon_e_smile.gif)