RetroPrinter Support

Hello,

i just received the v4 retro-printer module an configured it to print on a network printer and write a pdf file. But i only get a RAW file, which looks great by the way but nothing else happens. No file in the pcl folder and in the retroprinter or retroprinter-error file. Also no print on the network printer which i have configured in cups and printed a test page succesfully.

What i´m missing? My first guess was that the retro printer does not get the end command, but then i read that the end depends on time. And i writes a raw file, so therfor data is comming. Hope you can help me.

Thanks in advance
Michael

Welcome to the forums.

You are correct in that we use a timeout setting (/root/config/timeout) to detect the end of a print job.

The location of the raw file can give some clues to the issue - if it is in any of the folders within /home/pi/data/ then the end of print job has been detected.

If it is sat in /home/pi/data/pcl my guess is that you have the emulation set to HP, but it is not valid HP output - so you may need some help to identify the correct emulation mode. It probably needs /root/config/emulation to be set to Epson.

If you have the emulation set to Epson already, then it is probably not valid Epson printer output so we need to check what emulation it should be!

Can you upload (or email) the raw file and I will have a look at it.

Hi,

the raw file is stored in the RAW folder. I emulated HP cause the network printer is HP. I tried before TXT and Epson as well, but there we also no files generated.

Hope the RAW file will help you.

Hmm - the raw file appears to be completely plain text which actually should work fine with either Epson or HP emulation - I would set the emulation to EPSON anyway.

The emulation setting has nothing to do with the printer you are eventually sending output to - it is what original printer would have worked with the equipment had it been plugged into the centronics / parallel port - so the retro-printer can understand the incoming data.

CUPS then handles printing of the generated PDF to the printer you have now connected over the network.

Can you please check that:
/root/config/output_printer is set to YES

Without that, the PDFs are only generated if:
/root/config/output_PDF is set to YES

If you are still not getting any joy, please email the contents of the /home/pi/data/ folder to our support @ retrroprinter.com address

We have noticed that one potential issue is if you have enabled /root/config/merge_pages

We need to find a better way of moving the PDFs once they are generated!

Sadly nothing changed..i mailed you my data folder. Hope you can find a solution.

Again thanks

I have had the opportunity to investigate this remotely and whilst we have resolved the issue (by changing the emulation to HP), something odd is going on.

Michael is running the Retro-Printer module on a Raspberry Pi 3B and it appears that the majority of printer emulators are reporting "ILLEGAL INSTRUCTION".

We have just tried using the same software on a Raspberry Pi 3B equipped Retro-Printer here and do not get that error.

I therefore wonder if it is an interaction with the CUPS printer which has been installed. We will investigate further, but has anyone else experienced similar?

Hi, I'm reposting because the message disappeared for a reason I can't explain.
Maybe an unseen captcha?
If not, I hope you didn't think it was a troll, or that there was nothing personal, or that someone wasn't afraid of technical information
(last time nobody bothered to reply to my offer of help with the packaging... maybe the response was also lost).
Or maybe the compilation flags are "confidential" information .
I hope not.

In any case, the "illegal instruction" error is certainly not due to an installed network printer.
---

Hi, same problem on Rpi Zero WH here.

This is a well-known problem when using certain compilation flags.

The main differences here is the instruction set of the cpus in use.

Overview of RaspberryPi architectures:

5: ARMv8.2
3B, 3B+, 2B 1.2: ARMv8
2B: ARMv7
1A, 1A+, 1B, 1B+, Zero WH: ARMv6

Note that Rasbian targets the ARMv6 instruction set for the greatest compatibility (Debian ARM targets ARMv7).

Here, with version 3.20 of convert-escp2, gdb crashes with "illegal instruction" on the first assembly instruction of main(): movw, which is unknown on ARMv6 platforms.
Your binaries at least up to 3.16 worked on ARMv6.


You seem to be using flags like -O3, -Ofast or --ffast-math, so you're giving the compiler the information that the program is likely to run on THIS particular machine, and you allow it to generate aggressively optimized code that it will not be able to guarantee as "safe" in all situations.
Some optimizations will attempt to detect the instruction set of the CPU on which the program will run.

Obviously, we're not talking about the mtune, march or mcpu flags here, but it's a well-known fact that the use of such optimization flags (especially Ofast or ffast-math) should only be carried out in carefully studied and benchmarked use cases, in order to define whether the advantage is real and the calculations do not become erroneous, and all this on a rigorously written and mastered code base (things that break are often doubtful in the first place).
Most of the time, the code generated will be faster (but not always), but will frequently take longer to compile and even more memory to execute.

These optimizations may be worthwhile in very limited use cases, but they take you far away from a guaranteed compatibility on the platforms you're aiming for.
If the CPU is of a certain version (probably known only to the manufacturer, or it's a rebranded CPU as found on some non-genuine RaspberryPi) to break this compatibility.

I don't think these flags will be useful for the various retroprinter projects that don't do intensive calculations based on spaceship trajectories, celestial mechanics or AI...
The compiler won't make the code faster if it's badly written (or only to a limited extent).
In short, it's generally not something you want. Debian uses -O2 by default for all its programs.

TL;DR: Try an -O2 compilation :p
It will be understandable if you feel that exotic configurations are not your target.

Regards

Thanks for the information - yes, I did wonder if some of the flags we were using might be too agressive for non ARM v7 architecture.

I will change the compilation script to use -O2 (we used to use -O3 and now use -Ofast) would that affect it?

It *can* be a part of the problem. There is something on your compilation chain (gcc params, cpuinfo, chrooted env, etc.) that triggers a compilation for ARMv7 instead of the usual Raspbian compilation target which is ARMv6.

In any case -Ofast/-O3 are not *safe*, but that may be another problem. BTW -O3 worked fine but it may be a combination of new code added + compilation flag. The workings of compilers are complex, to say the least.

The test is simple, the following command should return nothing:

$ objdump -d convert-escp2 | grep -i movw

Since 3.16 (not included), the instruction is here.
In any case, for now without changing anything, your code will work on "recent" and not "exotic" archs without any problem.


---

It is not the correct place, but I'd like to take this opportunity to tell you that your Rasbian update is partial.
The /etc/apt/sources.list.d/raspi.list file is still set to Buster, not Bookworm.