File size limits for JV33 ink jet printer

[lsandersj]

Does anyone know about any file size limits based on printing resolution?

I am printing a 53 inch wide by 36 inch long image on a Mimaki JV33 at 720x1440. The printer quits at about 13 inches of length. I am told I need to reduce the resolution to be able to print the full image.

I am using Wasatch Softrip on a quad core machine with 8gigs of ram. All my images are RGB tifs at 250 to 300dpi and I've not had this problem on other printers.

Has anyone else encountered this?

 

[FatCat]

If your native image is 36" x 53" sized at 300 dpi that is a huge honkin' file - especially if you are using TIFF or JPEG. Have you tried a PDF?

Also, you should really be able to drop down to around 100-150 dpi. I get excellent results with lower resolution files through Wasatch and my Mutoh. I don't have to use standard prepress specs like you're ripping to an imagesetter.

 

[Rooster]

That's less than 500 MB for the input file size. Who told you you need to reduce the image resolution for the JV33 to handle it?

I would say you're probably having some sort of communication issue between the printer and rip that's causing it to cut out. I've printed panels twice that size on my JV33 using my wasatch rip without any issues. My resolution may have only been 180 dpi but at twice the panel size, that's still the same size file or even larger in the rip.

 

[lsandersj]

File size limits

That's less than 500 MB for the input file size. Who told you you need to reduce the image resolution for the JV33 to handle it?

I would say you're probably having some sort of communication issue between the printer and rip that's causing it to cut out. I've printed panels twice that size on my JV33 using my wasatch rip without any issues. My resolution may have only been 180 dpi but at twice the panel size, that's still the same size file or even larger in the rip.

Thanks for the reply Rooster and I think you are closer to it than the answer I got elsewhere. Im wondering if there is something going on with the spooling/windows 7/printer. Wasatch will sit there sending bytes and the progress bar keeps moving but the printer is stopped. finally after many minutes the printer will resume and finish the print but leave out about 2/3 of it. It actually makes the final passes and finishes the edge. I would expect it to leave the edge unfinished so it appears the data is getting dumped until the finish. Unfortunately the image is a repeating pattern so I can't identify which portion of the image is being left out. I haven't got a clue but I mention this detail so that maybe someone far more knowledgeable than I may recognize what is going on.

 

[SightLine]

Yeah I do not think there is really a limitation on the printer itself. As far as I can tell - as long as it keeps getting data, the only true limit will be the length of the roll you have loaded. You can change/add ink on the fly but changing the roll will interrupt it.

On a wall graphic we did a while back (this was for a hallway viewed up close with photos, some fairly tiny text, and other graphics) the final single flattened tiff image @ 100 dpi was right about 2GB. Flexi chewed it up and print it as one single 120 foot peice with no problems and the printer ran it perfectly. That particular one was run at 720x1440 16 pass.

I think on your scenario (the resolution is higher than it needs to be but that is not the issue) something is choking on getting the machine the data. Either hard drive speeds, connection speed to the machine, the RIP itself, something... I know on Flexi you have the option to "print while rip'ping", or you can set it to fully rip the file before it starts printing. If the rip is choking and cannot rip the file fast enough to keep feeding data to the printer you may need to see if there is some option to let it fully rip the file before it starts sending the data to the printer. Once data starts getting sent to the printer, the printer needs that data to be continuous until it has the full job printed.

 

[Rooster]

I have on rare occasions seen my JV33 stop mid-print for no apparent reason. It's usually just a case of putting the machine back into remote mode to get it to pick up the printing where it left off. Just as if you had an ink cartridge go empty mid-print, except you don't need to swap any ink carts.

The only time it didn't resume was when I was away from the printer for an extended period and the data communication probably timed out due to inactivity.

My JV33 has an annoying habit of spontaneously ejecting ink cartridges. There's one cart slot that is worse than the rest. I think the random stops in printing are related to the ink cartridge connection. I've seen the worst one pop-out and then go back to green status without my pushing the cart back into the slot. As if the vibration of the machine was causing a connection to be lost and then it comes back on it's own. I'm pretty sure this is the root cause of my mystery stops, but they occur so rarely that I haven't bothered testing to confirm this.

If your machine has this same annoying trait it might be something to look into. Something clamped to the front of the ink cartridge support tray to hold the carts in place may solve your problem. Or you could just do what I do and give the carts a little extra push into their slots a few times a day to make sure they're seated properly.

 

[signswi]

Highly doubt it's the printer -- we have a JV3, not a JV33, but I routinely print files in excess of 4GB without issue using Onyx ProductionHouse. Could be Wasatch or the windows spool. Does Wasatch have somewhere you can adjust how much is prebuffered to the machine?

Have you updated all your drivers?

 

[MikePro]

its not the printer, its your rip computer....

either not enough memory to handle the file your rip may be generating when you archive your work or you don't have enough RAM to handle the file your working with in the first place. I've run files on my JV3 (onyx10 rip) that were on the better side of 20GB before w/o issue (9ft x 200ft, one file @ 150dpi, handled all my tiles/overlaps just fine)