November 8, 2014 at 5:12 am #1997ezrecParticipant
Line 9 might be the in-pen temperature sensor output for the ink pre-heater.
Does its value change from an initial (cold) power on, then stabilize?November 8, 2014 at 8:43 am #1998
Hmm. interesting idea. I have no long-term measurement yet. Line 9 looks quite similar to what is happening on one 13 though, only with lower voltage… .November 16, 2014 at 11:09 am #2006
V2 of the carrier hardware is here. I know don’t if and when one will be able to hack the CN642A, but when someone does, the 3D printed hardware to hold and interface with the CN642A is working. It hold the carrier, it holds the cartridges, and now they release too. I won’t say that this is the final iteration, but this one is manageable.
For anyone interested, click the following link to download it: Download here
Obligatory PhotoNovember 16, 2014 at 7:52 pm #2008
Nice! Getting better!December 2, 2014 at 11:42 am #2028
After our meeting with Ytec and seeing the Plan-B@work we spend some time reverse engineering the signals between a HP7500A printer and the CN642 Head.
All working files will be uploaded to a Google drive so other can look at the data.
Appart from the low speed signals < 1Mhz there are 4 LVDS channels (1 clock and 3 data) we added a LVDS receiver to the breakout to be able to grab these signals. It seems there is no encription and it looks like a straight forward shift register (at least for the black) the other 2 LVDS channels control the other 3 colors. Allot more looking at bits is needed..
Feel free to dig through the files in the google drive and dont hesitate to comment. More files will be added over time.December 2, 2014 at 11:44 am #2029
link to the google driveDecember 2, 2014 at 9:36 pm #2031
I was really looking forward to a post on the forum by you guys. It seems promising that the data is not encrypted. Hopefully it is possible to reverse engineer it. All the electronic and software work on the printhead is (sadly) beyond my ability and I am really itching to design and build a full color 3DP printer.
I will download GTKwave to see if I can make any sense the data.December 2, 2014 at 10:11 pm #2032
Very very cool! Thanks so much for publishing this. I’ll try to get GTKWave running on my Mac now.December 3, 2014 at 8:25 pm #2034
Is the OPA2134UA the chip you used to read the LVDS? Or do you have a better chip for this? Also, when simulating those signals, what would be the right chip to generate the differential signal?
I am a bit surprised by the very high frequencies that go over this line. This can not be created with the Arduino. I hope that a RasPi can output signals that fast – I have not yet mastered FPGAs yet 😉December 3, 2014 at 8:42 pm #2035
The OPA was just a random op-amp i put in the sch to remind me there was one on the small PCB next to the printhead..
The LVDS receiver we used in the end was a DS90LV048A but we still get 100Mhz noise 50% of the time when there is no signal. any pulse you see that is less than 20ns you can ignore. I put the datasheet of the LVDS receiver in the eagle folder and added a Scan of the printout of the nozzletest that i used to trance the signals.December 3, 2014 at 10:39 pm #2036
Oh, OK. That makes sense now. I will try to get a transmitter/receiver pair to hack around a bit. Maybe the noise can be reduced with some R/C between + and – signals? The documentation show a 100 Ohm resistor.December 3, 2014 at 11:05 pm #2037
Looking at the scans, I see 24 times (later in the scan even tighter) a 10ns or 20ns pulse after the “lower” encoder sees a line. I don;t think that that is noise as there are times when these spikes do not show, plus they are evenly distributed, and lastly, assuming 10ns is 0 and 20s is 1, give a very simple binary encoding without needing an external clock source.
Do you have an idea what the remaining signals are.
BTW: it’s very nice to see the acceleration and deceleration in the light sensor sampling 😉January 12, 2015 at 2:20 pm #2106
Looking at the all the signals together on my scope, i assumed that high signal to be a 1 and low a 0 this also fits with the amount of data needed for the nozzle’s and there is a clock signal on one of the LVDS lines.January 12, 2015 at 11:22 pm #2107ezrecParticipant
Given the commonalities I’m seeing for the various printheads (LVDS, shift registers, etc) maybe it’s time to start thinking about rolling our own pen controller electronics.
I would see the basic idea as a SPI bus to the electronics, along with a ‘dot clock’ line, and a ‘fire’ signal.
The connection from the electronics to printhead would be N bits of LVDS output.
The SPI bus would load up a SRAM ring buffer on the electronics with the line to print, N bits wide, by M dots, by F fires.
On every ‘fire’ signal, the next set of M ‘dots’ (N bits per ‘dot’) would be sent to the printhead at the ‘dot clock’ data rate.
The ‘fire’ signal could be directly connected to the microcontroller, or to one of the optical encoder outputs from the printhead carriage if using the DC motor + encoder from an existing carriage.January 16, 2015 at 8:01 pm #2116
I like the idea a lot. It would make it useful for everyone trying to make a machine with inkjet, not to mention the possibility of using it for different printheads if they really are that similar.
Sadly I am next to useless when it comes to the printhead, so I am forced to wait you guys to hack a new printhead before I can start on the next printer. I will make a few concept drawings of what I have in mind for the next printer, because I can use feedback on it.
- You must be logged in to reply to this topic.