Christian @ 2CT Media
Active Member
My tests also include no quickset.
I'm going to try this later. I had this issue escalated to engineering when I called about 3 weeks ago on this and haven't heard anything back on it.Over the last hour I tried to replicate the issue you have described and I think I may have found what is incorrect. I know i can hear the groans already, but it has to do with how your quickset is set up. Since each page has a different cut path assigned to it, you need to regard each page as an individual job. In the quickset settings, under the Multi-page PDF File settings, click on "Submit pages as individual jobs" to enable. Then each page will be brought into RIP Queue with its own independent cut path assigned to the file. If individual jobs is not selected, you are telling RIP Queue that the pages are all the same and only one cut path page is required.
View attachment 173488
I will discuss with my team about making improvements to this area for better understanding, but it is not a bug. It is however a job handling issue that needs to be better understood. Each page is different - the print settings maybe the same but the cut information is not, therefore, it must be handled as independent pages.
All files opened in RIP Queue use a quickset. Most just use the <Default> which does not have cutting enabled unless you change it in Edit Quicksets.My tests also include no quickset.
So you are saying you have enabled paneling for a long job and it is paneled into 4 sections. I will investigate that scenario.It's not the submit pages individually option, I have that one done and I never have an issue with it. Maybe if you don't have a check there's another issue though ..
If you tell Onyx your page size is 54 inch by 12 in, then you print 310 in by 50-in tackles so it sends it as three different pages to your printer, only the first one generates a barcode and cut, the other two pages it sends to the printer will not generate anything in cut server.
It's a pain because I can tell Onyx to use 4 ft tall pages, and send a hundred feet of contour cut decals and it will split them into 4 ft sections ... On the latest version it still splits them into 4 ft sections, however only the first 4-ft section has a cut file and then the rest of the material ends up garbage.
So maybe it's two separate issues with the multipage PDFs
Well, can you get them to fix that? currently, when I have parking meter decals, each decal is it's own artboard (page in a pdf). I don't want to send them separately because there are upwards of 100 pages in each PDF. I don't want 100-300 different jobs in my rip queue. It works great now - but the upgrade would be a downgrade in this respect.Over the last hour I tried to replicate the issue you have described and I think I may have found what is incorrect. I know i can hear the groans already, but it has to do with how your quickset is set up. Since each page has a different cut path assigned to it, you need to regard each page as an individual job. In the quickset settings, under the Multi-page PDF File settings, click on "Submit pages as individual jobs" to enable. Then each page will be brought into RIP Queue with its own independent cut path assigned to the file. If individual jobs is not selected, you are telling RIP Queue that the pages are all the same and only one cut path page is required.
View attachment 173488
I will discuss with my team about making improvements to this area for better understanding, but it is not a bug. It is however a job handling issue that needs to be better understood. Each page is different - the print settings maybe the same but the cut information is not, therefore, it must be handled as independent pages.
So you have a file that is 100s of pages, independent, different image, all printed the same and cut the same. The only thing different would be a number or color. If so, you are good to go without individual pages. Your situation would have the print is the same settings and your cut is the same settings so my scenario still applies. If each page is a different cut path, then the pages would need to be independent. In fact your situation would be a huge problem since each independent page would have its own bar code and registration - so that would not work. You can continue to use it as you have, as it is the preferred method for your situation.Well, can you get them to fix that? currently, when I have parking meter decals, each decal is it's own artboard (page in a pdf). I don't want to send them separately because there are upwards of 100 pages in each PDF. I don't want 100-300 different jobs in my rip queue. It works great now - but the upgrade would be a downgrade in this respect.
I have been able to replicate the issue and have reported it to the appropriate people to have addressed.So you are saying you have enabled paneling for a long job and it is paneled into 4 sections. I will investigate that scenario.
Even though it is not meant to be necessary, it is always a possibility to make the cut files manually in the design document and use the PDF files in GoProduce to cut them afterwards. It may take a bit more time on certain documents, but it is a very safe and good way in many cases. For example allowing you to modify the cut after print, if necessary. Cut file Layers: Regmark / Thru-cut / Kiss-cut and Print file Layers: Regmark / Design does the trick...Just to give everyone a heads up, there is a known issue in Onyx 24 where printing multiple pages will not generate a cut file for each page. I have a job to print a few hundred safety signs, I'm printing on vinyl then mounting to coroplast to cut out on our summa F1612. i set my page size in onyx to 48"x96" and bring in my files, onyx nests them into 20 sheets of coro, I printed the roll and went to cut them and realized that onyx only generated 2 cut files instead of 20, a quick call to onyx support reveals that this is a known issue they are"working on" I asked if this issue was ever posted on their website or sent out in a bulletin and was told that Onyx does not publish their known issues.
So now I have a full roll of vinyl, alminate and ink headed to the dumpster, luckily I checked the first sheet before i mounted the other 19.
What is happening is this, say you need to print 100 copies of 3 different signs on Coloplast, in onyx I would set my page size to 48x96 and onyx would nest the signs into however many sheets I need, each sheet would get it's own barcode and cut file for the digital cutter to read.Hmm, maybe I don't understand the new quirk. When I read the OP, it sounded like Onyx 24 would only honor the cut path in the first page, and not apply the cut paths in all of the pages. The cut paths are the same in each page, the only difference would be a number in the artwork. I do the variable data merge in Illustrator, and save as a PDF with lot's of pages.
I haven't upgraded yet, so I have no way to tell what would happen.
Since we're fixing bugs... I've had a bug since onyx 22 thats still there in 24... On The Epson resin printer, if you load a media and then click get media info / size, onyx will crash. Then when you re-open it... itll get it perfectly fine without crashing.I have been able to replicate the issue and have reported it to the appropriate people to have addressed.
This is not the issue I have, my issue is if I need to print say 500 copies of something and set my page length to say 96", onyx will nest the files and it should generate a cut file that it send to cut server for each 96" page, however onyx is not generating a unique summa barcode for each page, all the sheets will have the same barcode, even if the cut paths are not the same.Over the last hour I tried to replicate the issue you have described and I think I may have found what is incorrect. I know i can hear the groans already, but it has to do with how your quickset is set up. Since each page has a different cut path assigned to it, you need to regard each page as an individual job. In the quickset settings, under the Multi-page PDF File settings, click on "Submit pages as individual jobs" to enable. Then each page will be brought into RIP Queue with its own independent cut path assigned to the file. If individual jobs is not selected, you are telling RIP Queue that the pages are all the same and only one cut path page is required.
View attachment 173488
I will discuss with my team about making improvements to this area for better understanding, but it is not a bug. It is however a job handling issue that needs to be better understood. Each page is different - the print settings maybe the same but the cut information is not, therefore, it must be handled as independent pages.
Really feeling it tonight!
I have 950" of Decals to print... 15 different decals, between 50-100 of each. Cant just tell it to print 8 FT sheets and hit print... Nope... have to split the 15 files up into 8 FT at a time... and hit print once by one. So now My printers heaters are turning off and pre-warming about 25 times, adding 5 mins per print, ontop of me manually having to hit print 25 times I feel like I would have been better off spending an hour manually nesting everything in illustrator and using CM4....
NM.. its faster for me to go back to onyx 22.... I'll be back once that bug is fixed!
Yeah and I got the V22.5 upgrade just so I could get the free upgrade to 24. I will be mighty unhappy if that happens. I solely got this so I could run my UCJV330 on v24 which this printer still is not supported yet.The sad part is, Onyx will fix these issues in their next major release... And expect their customers to pay to get the bug fixes. Just like the previous versions.
I thought about that and tried that. However it wasn't nesting, or at least it would not rotate to make use of most of the media... Print is individual jobs was taking up an extra 30 ft of material.Potential (untested) workaround that might be worth testing....
Change Placement strategy to Print jobs individually. In general settings, change print triggering to Automatic (Automatically start printing)
**Make sure to load and set up your repeats settings etc. before you check "Automatically start printing" as it will just start pushing jobs.
Not sure if this will work, but would save you from having to hit print after every job etc.
We use this strategy when sending multiple files to our Summa roll plotter and want to limit length of jobs/generate multiple smaller cut paths. Works well.