I was trying to output to POS printer directly fro 1c:Enterprise, but got error on linux. The same code works fine on windows. If I output to the same device (/dev/ttyXXX) from the console everything is just fine. So I am confused: - could it be some behavior that tries to open file with restrictions not available for device files? - which username does 1c enterprise use to run under linux? (file mode) It could be group restriction
In File mode 1C:Enteprise applications run as a current user. And yes, if the user does not have appropriate permissions to write to the device, the operation will fail.
Do you use File/Print command or some other option? Did you try to print using other application? What do you try to print? MXL or maybe there is some unsupported data by the POS?
No, I do not use File/Print. I use TextWriter.Write("/dev/ttyXXX") to output to device directly. The same code works fine on windows, there are no problems with forbidden symbols or printer incompatibility. There are also no problem with the user who running 1C:Ent platform to write to this device, it passes every test. The user is inside appropriate group with the permissions needed to write. The problem is just with 1C:Ent platform. ITS says that under linux I just have to change "COM" -> "/dev/ttyXXX", but It does not work. If you "Echo" to the exact same device it works just fine.
Could you, please, give me the following additional information on the issue?
1. Can you print anything to the same printer from the same 1C application using standard 1C:Enterprise printing features (rather than TextWriter.Write)? Say, if you run any report and then send it to the printer with "Print" menu command, will it work or not?
2. What is the purpose of sending strings to the printer one by one instead of preparing the entire document and then printing it out with standard "Print" feature?
3. I need a tech log of the issue, so could you, please, do the following:
Stop the app one click before the start of the printing procedure
Copy the logcfg.xml file (see attached) to the /1cv8/conf catalog on the client computer (the one 1cv8 is run on)
Run the printing procedure
Archive the content of /var/log/1c/logs catalog and sent it to me
1. There is no point to print normally to this printer because it is a fiscal printer, it accepts special codes like "cut the paper" o "print a barcode", and it is times faster than working directly (without cups subsystem)
2. It is the way it is designed to work. Graphics mode for this printer is very slow and it is not for what the printer is designed.
3. I will make a test PC for this problem, and will provide you with the access.
1. Alexey, I didn't mean you should change the printing method. I just need more information to diagnose the issue. Can you try printing anything to this printer in more conventional way just for test?
I haven't tried to use standard printing because there is no need. I have not even install printer driver for graphical interface because it functions like an old matrix printer and these printers do not used in graphics mode.
Moreover on windows if you install printer drivers for the same printer it could interfere and block port for it own (driver) reason and direct printing could fail. Without any drivers on windows outputting to the printer port works just fine. (COM, LPT, net use, Virtual Com and so on)
Also I could confirm that there is nothing blocking 1c to successfully output to the printer port because I could output with echo command some data to the printer port with success while 1c is running. After an attempt to output from 1c the port is blocked, 1c shows error on writing to device file and I need to disconnect the printer to make it available again to write.
While I am preparing a tech. log, could you help me with workaround. Is it possible to run some bash command within 1c in linux? Another solution could be UPOS interface for 1c. Is there any driver for connecting UPOS devices? O some native component to output directly to some device?
