Yet another weird question
-
Hi All,
So, I want to automate a laser marker. To all intents and purposes it's a printer. If you print to it it will mark what you print.
However, I'm adding a plate feeder to it. The firmware for the plate feeder makes it harder to print multiple jobs, and multi page jobs.
I also want it to work over a network so many users can print to it, and it marks automatically. Essentially making it act exactly like a normal printer.
So, what I need is some form of print server software which will allow me to queue up all the jobs that get sent to it, split multi page jobs into individual jobs, AND have scriptable control so I can use a hardware module to monitor the status of the laser (it has I/O) and send down each individual job when the laser is ready.
All Windows based.
Any starting points?
-
@ben_warre How hard is it to control the current software via. WSH scripting or PowerShell scripting?
I'd be surprised if you could find something off-the-shelf to do what you need here.
-
Yeaaaah you're not doing that unless you write a print driver that does it.
Source: Work in print industry, know WAY too much about what you're talking about.
-
@blakeyrat I would normally work with the actual software but this time want to print directly from Crystal reports.
@Weng I was hoping something might exist.
After posting I did write most of a print ish server which will involve any user printing to pdf which will be stored in a specific folder. I then run a service which can get the status of the laser, split pdfs to single page pdfs and print via command line AcroRd32...
In theory it will work but it seems my PDF splitter makes files that can't be printed. Guess I'll be firing up GhostScript on Monday.
We shall see.
-
@ben_warre said in Yet another weird question:
Guess I'll be firing up GhostScript on Monday.
Solve a problem with GhostScript. Now you have 2 legal problems.
-
@ben_warre you may want to look into qpdf for the page splitting.
pdftk is another one that may come in handy...
-
OK, so I have this working now.
It involves a few external executables and sending local files to the printer.
Another silly question, in line with the topic title:
Would it be better to use a RAM disk of some sort to save repeated hard drive access, or is that not something to be concerned about nowadays?
Thanks,
Ben
-
@Ben_Warre said in Yet another weird question:
Would it be better to use a RAM disk of some sort to save repeated hard drive access, or is that not something to be concerned about nowadays?
I don't normally worry about that. If it's a problem bottleneck for your application/situation, slap an SSD in for temporary space. Sorted!
-
@Ben_Warre said in Yet another weird question:
Would it be better to use a RAM disk of some sort to save repeated hard drive access, or is that not something to be concerned about nowadays?
Completely unrelated, our game servers load the entire OS into RAM by nature of how the image is built. It's pretty Zippy, but losing 600 mb of RAM in a 2gb VM is annoying.
-
@Tsaukpaetra I've once worked on a semi-embedded platform with 256MB flash memory and 512MB RAM, half of which was taken by exact copy of flash memory.
-
@Gąska said in Yet another weird question:
@Tsaukpaetra I've once worked on a semi-embedded platform with 256MB flash memory and 512MB RAM, half of which was taken by exact copy of flash memory.
I'm betting you weren't running Windows though.
-
@Tsaukpaetra said in Yet another weird question:
@Gąska said in Yet another weird question:
@Tsaukpaetra I've once worked on a semi-embedded platform with 256MB flash memory and 512MB RAM, half of which was taken by exact copy of flash memory.
I'm betting you weren't running Windows though.
-
@PJH said in Yet another weird question:
@Tsaukpaetra said in Yet another weird question:
@Gąska said in Yet another weird question:
@Tsaukpaetra I've once worked on a semi-embedded platform with 256MB flash memory and 512MB RAM, half of which was taken by exact copy of flash memory.
I'm betting you weren't running Windows though.
Digging the flat design, consider adjusting your accent colors though...
-
@Gąska said in Yet another weird question:
@Tsaukpaetra I've once worked on a semi-embedded platform with 256MB flash memory and 512MB RAM, half of which was taken by exact copy of flash memory.
-
@blakeyrat and that's relevant how exactly? Was it the first platform you worked on professionally or what?
-
@Gąska Roughly 50% of the machine's RAM is occupied by its ROM.
-
@blakeyrat said in Yet another weird question:
Roughly 50% of the machine's RAM is occupied by its ROM.
Ugh, that's reminded me of old systems that used banked ROMs. Swapping around the address space like that without a memory management unit to help is really ugly…
-
@dkf said in Yet another weird question:
Ugh, that's reminded me of old systems that used banked ROMs. Swapping around the address space like that without a memory management unit to help is really ugly…
-
Oh for the days when "Core" was core!
-
@blakeyrat said in Yet another weird question:
@Gąska Roughly 50% of the machine's RAM is occupied by its ROM.
Unless you turned off the ROM mapping...
-
@anotherusername said in Yet another weird question:
@blakeyrat said in Yet another weird question:
@Gąska Roughly 50% of the machine's RAM is occupied by its ROM.
Unless you turned off the ROM mapping...
And slowed things down massively in many (most) cases. Quite often the ROM were extremely slow (as slow as 650nS)
-
@TheCPUWizard Hm? I meant turning off the ROM mapping so that you could read from the RAM instead. Ordinarily, if you read from ROM-mapped addresses, you would read the contents of the ROM. Writing to those same addresses would always write to the RAM, but the contents of that RAM could not be read back unless you turned off the ROM mapping.
I never actually played with a C64, though, so I only know what I've read about it. My understanding of this could be wrong.
-
@anotherusername said in Yet another weird question:
@TheCPUWizard Hm? I meant turning off the ROM mapping so that you could read from the RAM instead. Ordinarily, if you read from ROM-mapped addresses, you would read the contents of the ROM. Writing to those same addresses would always write to the RAM, but the contents of that RAM could not be read back unless you turned off the ROM mapping.
I never actually played with a C64, though, so I only know what I've read about it. My understanding of this could be wrong.
You are correct; the KERNAL and BASIC ROMs each occupy 8K in the upper areas of the C=64's memory space, and you can turn them off if you don't need them.
Other things also take up space, such as the I/O in the $D000 block, the (movable) areas of RAM used by the screen and sprites, and the interrupt vectors. Still, you can use almost all of the 64K of RAM available with careful enough programming.
