Ytec3D Forum

im interested that , wemos lolin32 -esp32 have more pinout and more ram . is there any experiences hp45 printhead with these?

ESP32 is actually a bit short on pins. It should have enough pins to control an HP45, but there will not be many pins left for other things the way I drive them. The ram and other peripherals are very nice though, so it might be a cool idea. I have no experience with driving HP45 with an ESP.

I do know SpriteTM drives other printheads with an ESP.

Dear, Yvo.

Do you have any ideas, why such shift can occur? At the moment, this is with V3.02 driver. I have not changed it to V4 yet as I tested V3.02 and wanted to try that one first.

Interesting, but this shift happens randomly and it might occur for one layer, but others can continue normally. This part had 50 layers and, for example, it can have 2-3 such shifted layers. Also, this shift is not the same all the time, different areas in a bit different way can be shifted.

Thanks.

Vaidas

Is this shift also in the preview image, or only when it is printing.

If it is in the preview image please send me the file so I can alter the parser.

If it is only when printing there might be an issue in the updating of the coordinates of the printhead. It might be that the GRBL did not send a proper coordinate, or that it was not sent to the HP45. I'd have to look in the code to see where it might be fixed. Not sending the coordinates might be a workaround, though in my experience the HP45 encoder signal has some minor loss on it.

That shift is only when printing. I double checked and it is good in preview window.

Is there anything I can do to help you finding the reasons? For now, this is not deal breaker for me as I am just starting printing and getting at least something printed, so such shifts are not huge problem, but if that can be addressed and perhaps implemented in V4, that would be cool. I will later try V4 driver and see if it gets better. I also had an idea, perhaps RPI can cause this? If it lags for some reason and does not send (or receive) data to GRPL in time, could that be the reason?

The Pi being too slow could be the reason, though I would have to verify it first.

The function which would be causing you the trouble is "self.InkjetSetPosition()" in "def PrintSVG(self):" in "Oasis controller.py". In my version this one sits around line 650. There is a second one at around 490, but this one is only called at the start. This one updates the position by writing the GRBL position back to the HP45. If this either fails to send, or sends an older position this might be the cause of the shift. Raising the sleep before the SetPosition might also already fix it. You can also comment both SetPosition's in PrintSVG and see if it works. You will need to manually set the position before printing then though.

hi,
for hp45 controller version V1.01
V var: variable printhead voltage. Usually between 9 and 12V;
12V: address side 12V input;

can i supply with same 12 volt power supply?
and also amper?

You can supply both with 12V under most circumstances. I have had examples where Vvar being 12V burned out nozzles, but that is only something to keep an eye on. An HP45 needs around 3A is you want to be save. Anything lower than 2A is not adviced.

And also can we make test with TEENSY LC? can we use TEENSY LC ?

when i use test.ino teensy lc output voltage =1.8 volt. and also overheating problem. can anybody help?