Standalone controller V4.0

Powder and inkjet printing
User avatar
dragonator
Site Admin
Posts: 595
Joined: Fri Aug 14, 2015 4:48 pm
Location: The Nethelands
Contact:

Standalone controller V4.0

Post by dragonator »

The new year brings with it the desire to make a new controller for the inkjet.

So far I have been using V3.02. This is a not released version of the controller that powers Oasis, but with some upgrades that makes it use DMA. This works well, and it has proven to be reliable, but if I want to actually provide this as a general inkjet tool, I want to make a few changes.

The list of requirements is as follows
  • Move to a single board. In assembly time the double board is not that bad, but it makes it a challenge to do any sort of debugging on the bottom board, where all the high power stuff is.
  • Move to a better Teensy, the V4.0 and V4.1. I am not yet ready to get rid of the Teensy's, but better ones are now available. I was hesitant at first because the OctoWS2811 library that I use was not yet supported, but now it is. A better Teensy gives me more speed, more RAM, and more firmware options in the future.
  • Move the inkjet to a single DMA bus. The current V3.2 controller uses 2*8bit busses for DMA. This works, but requires some nasty hacks to make sure it works with extra chips. I cannot have full control of the 14 primitives with just 8 bits, but I can add shift registers to the bus. This allows me to use a register clock, latch and 2 data pins. The TLC59213 latch and clear, and the address clock and reset pin, giving me full control. Shift registers require me to clock in the data much faster (8 bits of data in 2.5us) but the pins that come available with this will be very helpful for:
  • Make the board be able to test itself as much as possible. Distant debugging is challenging enough. People giving me vague issues without me being able to see what happens sucks. I want to monitor voltages (12V and VHD can be separated). Test the addresses and primitives (at least that they are somewhat operational) and test the mosfet and testing circuit. All of the tests I have designed so far have failure modes that I can miss, but it takes care of the basics.
  • More LED's on board. I want to be able to see what the board is doing and if it has power.
  • Make it capable of logging and working from SD. I have designed it for the Teensy 4.0 footprint, but I will make sure that the Teensy 4.1 also fits the footprint. It should be possible to use any Teensy after 3.2 in this controller, but I will support 4.0 and 4.1.
  • Keep the board as close to the current form factor as possible. This will require me to move the shift registers, the 4017 and 4081 to SSOP packages instead of the SOIC packages, but I will order stencils as well, so it should be fine.
  • Try to keep the board single sided. Double sided assembly sucks. If I can avoid it (which it seems I can) it would be great. Worst case some passives would move to the bottom of the board.
The schematic is attached as a zipped pdf for anyone fancying a peek.

There is a list of firmware and software features that I have added and want to add, but for now this is where I will leave it. When this is done I hope to add a real manual to the site and maybe sell it to people who are interested.

I will breadboard the circuit first to make sure it work before I commit to fiberglass.
Attachments
HP45 Standalone V4.00 Driver.pdf.zip
(169.81 KiB) Downloaded 1389 times
Priyashree
Posts: 11
Joined: Wed Jul 17, 2019 8:40 am

Re: Standalone controller V4.0

Post by Priyashree »

Do you able to share firmware for above development.
User avatar
dragonator
Site Admin
Posts: 595
Joined: Fri Aug 14, 2015 4:48 pm
Location: The Nethelands
Contact:

Re: Standalone controller V4.0

Post by dragonator »

I will share the firmware when I am a bit further along. Quite a bit has already changed, and it might continue to change a few times more before I will order PCB's and lock the design in.

The Teensy 4.0 did not want to cooperate. It technically does not have DMA with direct I/O output, so they hacked this feature on top of it. This hack was something that I could not really modify. I then tried to get the DMA on the Teensy 3.2 to run at 10MHz to try and run the shift registers. While I got close with 5MHz, this would effectively halve the speed I can print at right now, from 110mm/s to 55mm/s, which I deem unacceptable.

The current design runs with a Teensy 3.5. This still has 4x the RAM, more speed, more pins and an SD card, and only costs a little more. It works the same way as the current 3.2 controller (that is not really shared :( ) with 2 full ports with DMA, sending out the data to the printhead. I have tested the Teensy 3.5 with a scope, and it is more than capable of doing this.

I have breadboarded the expected version so I can test it. I do want to test some of the functions, like the printing with a Teensy 3.5, and the extra tests. A more important reason I have make this full version on a breadboard is that I want to see why the HP45 will not print all nozzles at the same time. I have a few theories:
  • Higher than ideal voltage on the primitives (12V instead of the closer to 10V) is over-saturating the printhead, making it slow to refill the nozzles. I will test this by running it with a variable power on the primitives through my power supply.
  • TLC59213 cannot supply the required power. Depending on how you read the datasheet, the TLC59213 are not really capable of supplying the power required. I will see if the voltage does drop when printing with a scope, measure current with a shunt resistor on the output, and I will try to double and triple up on TLC's to see if this helps.
  • The pulldown resistors in the HP45 are leaking voltage to the other addresses, opening them slightly. I have had a few joyful encounters with the pulldown resistors in the past, in the nozzle testing functions. The printhead has a lot of pulldown resistors draining to the addresses. I added an extra resistor over the address circuit to keep the voltages to a testable level. It is possible that all inactive addresses charge enough to open partially, draining current reserved from firing resistors to non-firing ones. There a re several tests I can run to check this.
More updates when they happen.
HP45 controller V4.00 breadboard 210124.jpg
HP45 controller V4.00 breadboard 210124.jpg (360.82 KiB) Viewed 57028 times
Priyashree
Posts: 11
Joined: Wed Jul 17, 2019 8:40 am

Re: Standalone controller V4.0

Post by Priyashree »

Instead of TLC51923 ic , i have found Microchip HV583 of which is capable of driving Inkjet heads as well as it has serial to parallel gpio interface for driving.

Also I was guessing your code to driving print head using serial data previously when I studied oasis 3d code it was divided into two parts and address decoders and primitives. Could you able to explain , now what has been changed.
myying
Posts: 17
Joined: Mon Dec 16, 2019 10:16 am
Location: Taipei

Re: Standalone controller V4.0

Post by myying »

Hi!

Maybe it's a better solution ST L6452 cause of head temperature control. however there are both lack of adaptive voltage supply.
User avatar
dragonator
Site Admin
Posts: 595
Joined: Fri Aug 14, 2015 4:48 pm
Location: The Nethelands
Contact:

Re: Standalone controller V4.0

Post by dragonator »

I have ordered a batch of PCB's with the V4.0 prototype design. The breadboard gave me erratic readings so any result I would not have trusted much. On the PCB I at least hope to have stable results, though making alterations will be a bit more challenging.

L6452 is indeed a nice chip, but I find the supply to be way too unreliable to design around. I have a few chips, but most suppliers do not even have them right now.

HV583 seems problematic, since it has 128 outputs, but only 30mA each, so that is around 270mA per channel (if I can control all pins at once, which is questionable at this time). It also cannot handle less than 15V, so that also breaks the concept a little. Also clocking the data in is a challenge for me.

On the HP45 thread there is the UDN2987, which does meet most requirements. It can source enough current, at a voltage between 8V and 16V, is (barely) fast enough at typical speeds of 200ns, though at 1000ns max speeds, and it has a latch. It also is officially discontinued but is still in supply at some places. This chip is under consideration if TLC59213 power limitations do seem to be the cause.

The address and primitive are split because they are 2 different systems with different requirements. The addresses need 12V logic, but not power. Only one address is on at the same time, so the 4017 system does the 12V high side logic and the one address at the same time beautifully. It also gives me 1 logic line to go to the same address, which is important for the amount of logic pins available on the DMA bus. Primitives require a lot of power (12V at 300mA sourcing) at high speeds (300ish ns response times). A latch is really helpful here to make sure all pins trigger at the same time. The TLC59213 so far have been the best candidate, though they do seem to be over driven a bit. With 1 address next, 1 latch and 14 primitives I use my whole 2x8bit DMA bus on the Teensy.

Any serial to parallel chip has so far proven challenging. Keeping the primitives and addresses synchronized is very challenging. DMA I/O so far has proven the most reliable system because I can control primitives, the latch and the address counter from one system. This guarantees that everything runs at the same time. It also frees up my controller to do other tasks, which greatly helped my current print speed of 110mm/s (the previous best without DMA was 50mm/s)

When I have a better idea of the limitations of the primitive drivers I might change those, but first I want to see if they really are the bottleneck.
User avatar
dragonator
Site Admin
Posts: 595
Joined: Fri Aug 14, 2015 4:48 pm
Location: The Nethelands
Contact:

Re: Standalone controller V4.0

Post by dragonator »

I now have an assembled V4.00 board. The boards arrived yesterday and I couldn't help myself. Here are a few of the changes compared to V3.02.
  • It is finally on a single PCB. The 2 boards were starting to give me a headache.
  • It runs on a Teensy 3.5. This gives it more RAM, more pins, and an SD card slot (for logging and a larger data buffer)
  • The Teensy only uses the breadboard compatible pins. The Teensies have extra pads on the bottom. These are difficult to connect.
  • Integrated switching power regulator for logic voltage. The 5V is created with a switching regulator. This does increase the BOM size, but it saves big on heat generation. The regulator is mostly tucked under the Teensy.
  • Actual fuses. Pretty self explanatory.
  • The printhead driving electronics have been shrunk massively. The layout is now optimized to a point where I can fit all the printhead driving stuff right around the printhead connector. This optimizing also includes switching to TSSOP which is more difficult to solder, but if I do get to selling these, I will either order assembled or assemble these with paste stencils, pick and place assembly, and reflow soldering.
  • The board has LEDs for power and some functions. I may have went a big overboard here with all the things tied to LEDs, but I can now see what the board does and does not do.
  • The board can test itself now. Mostly. It can sense if all the voltages are there, it can test the test circuit and the driver circuit and warn if these are not working. I do intend to start logging data if there is an SD card available, but that is for the further future.
  • DC barrel jack. This is just more convenient if you want to connect it standalone.
  • More pins broken out for external functions.
  • Mostly compatible with the old board. Only 4mm wider (which should still fit the old Oasis carriage) and 20mm taller. The actual printhead holder will not fit because of all the pins sticking out the back, but this is the only part that needs some tweaks.
  • Fiducials for if I ever decide to make these on a pick and place machine. There is one in the works close by.
Now I did already mess up, so this board might not be final. The bottom mounting holes line up. The top ones do not. I am off by either 1mm or 2mm. I do hope to fix this in the next revision (or I will simply change the carriage since it already needs changing anyway). The LEDs might get stronger resistors because I am kind of blinded by these LEDs. The worst issue is that the encoder connector and the serial are flipped compared to V3.02. This might actually be a real hassle which needs fixing. With the next revision I will also order a solder stencil. I also think I can narrow the board by 2mm more, though I might just not to prevent unnecessary complications. If all functions do work I do seem to be at 'good enough' already.

Over the next few weeks I will test this design and get my software running on this. Now that I have the driver layer in an accessible place, I will also attempt to test why the primitives cannot fire all at once. If this yields a solution I will change the boards accordingly. Once I am confident this will work I will write a proper manual and hopefully turn this controller into something which can be made to work in more general projects, but I will ignore that for now to prevent feature creep and to stay focused on getting the basics to work.
HP45 controller V4.00 first assembled 20210228.jpg
HP45 controller V4.00 first assembled 20210228.jpg (393.02 KiB) Viewed 56474 times
Priyashree
Posts: 11
Joined: Wed Jul 17, 2019 8:40 am

Re: Standalone controller V4.0

Post by Priyashree »

Amazing...... Looking fantastic. Is it able to print some images.
User avatar
dragonator
Site Admin
Posts: 595
Joined: Fri Aug 14, 2015 4:48 pm
Location: The Nethelands
Contact:

Re: Standalone controller V4.0

Post by dragonator »

Commissioning the controller took way longer than expected. I had a few problems.
Wrong trace.jpg
Wrong trace.jpg (301.72 KiB) Viewed 55237 times
PXL_20210314_100448831.jpg
PXL_20210314_100448831.jpg (395.5 KiB) Viewed 55237 times
The first is that some unknown person decided that one trace did not need to be connected. It was easily fixed, but it does already mean that my prototype boards will need an update.

The other was in getting the controller to work. I created the new nozzle table according to the schematic. This gave an image that looked decent, but it did have a single shift in as seen in the image on the left. I thought that a primitive was swapped and tried fixing it by swapping primitives. I then measured every pin on the board and fired each primitive individually to make sure it was all working. I spent hours troubleshooting this.

Today I realized that the image is actually in the right row, only is it shifted to the side. I then remembered that which side each pixel is on is handled somewhere else. I updated that table and now it prints a fine image seen in the right.

All the old functions are now working and I can start to implement the new stuff.
PXL_20210314_085525543.MP.jpg
PXL_20210314_085525543.MP.jpg (360.27 KiB) Viewed 55237 times
Priyashree
Posts: 11
Joined: Wed Jul 17, 2019 8:40 am

Re: Standalone controller V4.0

Post by Priyashree »

@Dragonator Printing quality is seems okay compare to previous oasis 3dp version. Any special requirement of spi protocol. I think it's reducing the pinouts but increase the source code complexity.
Post Reply