General Question about Compatibility

[davlovsky]

We have a battery analyzer here with a DB-25 connector in the back. It is suppose to connect to a RS-232 serial dot matrix printer that supports the EPSON FX #1 printer configuration.

The following are the rest of the configurations:
The printer can be set to 1200 or 9600
baud. Other printer settings should be set to 8 data bits, 1 start bit, no parity,
DTR busy data protocol, line feed after carriage return, 10 cpi (characters
per inch). If the printer supports ETX/ACK (End of Text/Acknowledge), it
should be turned off.

Was wondering if the retroprinter setup would be appropriate for this application.

Ideally, we want to have the data captured to a file and uploaded to a network drive, instead of printed on a modern printer.

[RWAP]

Yes, the Retro-Printer can be used for this purpose, but we do not currently have a serial port version of the Retro-Printer. You would need to use a serial to centronics adaptor..

We have a very limited supply of second hand centronics adaptors so could provide one of those for £25 extra (you may need a DB25 to DB9 gender changer)

[davlovsky]

As far as the centronics adapter goes, I don't think I would need one given the workflow.
The battery analyzer has a db25 plug on the back, and it's connected directly to the computer via the DB25 -> DB9 adapter.
The battery analyzer is suppose to be hooked up to a dot matrix printer, but instead it's going to the computer.
I wrote a simple C# serial port terminal (like PuTty) but because of the ESC/P commands, I can only read text.
Whenever I try to capture plots/graphs (charge/discharge curves), it's basically gibberish (albeit somewhat intelligible).

WORKFLOW:
Battery Analyzer(DB-25) -> DB25/DB9 Converter -> Computer -> Serial Monitor/Printer Emulator -> Capture data -> Save data to network drive

[davlovsky]

Why would I need a centronics if there's a DB25 on the back of the battery analyzer and it's connecting directly into the computer via DB25/DB9 converter? I'm just capturing the data on the computer instead of printing it out.

[RWAP]

I am not sure what you are after...

The Retro-Printer is currently designed to capture centronics data (sent via a parallel port) rather than serial port. The DB25 seems to be a serial port from what you have said, rather than a parallel port.

If your serial port is going to be connected to a PC (Windows based) then you have a variety of Windows based applications to choose from which can capture and convert the data.

Our software is written in C and designed to be run on a Raspberry Pi (which is more portable and lower cost than using a WIndows PC). However, you would need a way of connecting the Raspberry Pi via the battery analyzer's serial port. We haven't developed a version of our software to run under Windows because that side of the market is already met, so far as I know.

There have been a couple of plug in serial port adaptors sold in the past for the Raspberry Pi, but these are no longer available (or at least weren't the last time I looked). I think these included hardware based handshaking, but I have no experience of using them (they seemed to connect via the Raspberry Pi's 2 serial i/o pins only). Our software would need to be adapted to cope with serial data with no hardware handshaking.

The serial to centornics port adaptor overcomes these issues by converting the serial port output into a centronics port which can then be plugged into the Retro-Printer.

You say that you wrote a C# serial port terminal and capture the output already. Is that on a Raspberry Pi or a PC?
If it is on a Raspberry Pi (or Linux box), then have a look at the free version of our ESC/P2 convertor written in C - http://www.github.com/RWAP/PrinterToPDF

If you need a Windows solution - then have a look at QPCPrint - https://www.kilgus.net/qpcprint/ - that is an excellent Windows based ESC/P2 convertor.

[davlovsky]

The serial port monitor's written in C# and is being run off of a Windows computer, but am not adverse to capturing the data on a Linux machine. I have plenty of Pis at my disposal.

I looked at the PrinterToPDF on github, but was having a lot of problems getting it up-and-running. I had tried compiling it on my Windows BASH Linux subsystem -maybe that was the problem?

Again, the serial port monitor captures the textual data correctly. But the graphing data is a little weirdly formatted, albeit somewhat intelligible. A better description of my problem can be found here: https://softwarerecs.stackexchange.com/ ... mulation-c

On the PrinterToPDF, does the original file need to be in a certain type of encoding? Right now, I have the serial monitor to accept either HEX or text.

Thank you for your help.

[RWAP]

I have responded on StackExchange:

Interpretation of ESC/P2 data to create meaningful output requires a lot of code. Viewing the output in a text editor is no help whatsoever - as the graph could be drawn by means of using one of the various Epson graphics modes (some of which are compressed), or it could be using Epson specific character tables.

Because your graph is shown by question marks (which sort of looks correct), the best guess is that the vertices are drawn using Epson specific character tables (which have various vertical and horizontal line combinations) and then overprinting with a graphics mode dump.

This is not easy - there are various Epson convertor written in C out there, including my own www.github.com/RWAP/PrinterToPDF - however, I have not re-created the numerous character tables and fonts in the freeware version which it appears you will require.

PrinterToPDF requires ASCII output - ie what is sent to the Epson printer without any processing or changes to it. VIewing the output in Word or a text editor will strip out a lot of the data and replace it with question marks (as you have shown on StackExchange) - because the Epson will be using character codes outside the normal range of printable characters.

Unfortunately, there are no full Epson character sets anywhere on the internet - I have had to create my own versions for v3.3 of the Retro-Printer software, but this is painstaking work and not something I am willing to give away for free as part of PrinterToPDF. That said - PrinterToPDF should still be able to print the graph (just not the vertices).

I am not sure why you are struggling to get PrinterToPDF up and running - others have managed it, but the idea was to present it as a partially finished project so that others could complete it to turn it into whatever they require - a standalone program, or a filter for example. Other than the character set handling and file handling, it uses the same conversion routine as is provided with the Retro-Printer which is proven to work with a wide variety of outputs..

If you pm me a copy of your captured output, I can run it through the Retro-Printer processor and check the output. It could well be that something in your C# code is breaking the Epson ESC/P2 rules making it even more difficult.

[davlovsky]

PM Sent.

[RWAP]

Having looked at a sample of the output captured, it appears that there is a problem somewhere in the C# code which initially captures the output.

Technically speaking:

I have run the raw data through the ESC/P2 convertor used by the Retro-Printer and through the QPC2Print convertor and both give the same output:
www.rwapsoftware.co.uk/downloads/Batter ... Output.pdf

The problem at the bottom of the graph highlights the issue:

This equates to offset 0x8c91 in the raw data, which gives the command:

ESC L 0x3F 0x3
followed by 959 bytes of character 0x3F

ESC L draws a bitmap image based on the next xL + xH * 256

So the command above gives 3 x 256 + 63 (0x3F) bytes of data = 831 bytes in total.
That leaves (959-831) 128 bytes of 63 unaccounted for (character 0x3F happens to be the question mark)

The correct command should have been:

ESC L 0xBF 0x3

0xBF happens to be 191. If the C# code does not deal with the upper character table (ie character codes greater than 128) then 191 gets converted to 191-128 (63)

It could be that the C# code is using a signed char to hold the captured byte or ignoring bit 7.

[davlovsky]

Very interesting. Learning a lot here.

The output you PMed me is pretty darn close, and I think you're correct about the ANSI/ISO encodings. For .NET languages like C#, it looks like 0 -> 127 represents the ASCII character set, and code point 128 -> 256 differ between "code pages". (source: https://docs.microsoft.com/en-us/dotnet ... r-encoding)

I guess the next question is, what code page would I use?
The following link lists various code pages along with their identifiers: https://docs.microsoft.com/en-us/window ... dentifiers