Printing Label Using DOS Shell

Marc_Velazquez · March 14, 2023, 7:04pm

In order to print labels for my production environment, I have used a server based print program (Label Matrix) that takes data from a table and can print a label to a networked printer. In order to accomplish this with Ignition I use a Gateway Event to open up a batch file. The batch file contains the print file (.qdf) I want and it invokes the print program to print the specific file.
Here is the Gateway Event script, triggered by the REPRINT_PALLET tag. The GWay_yes tag gives me a signal that the script completed successfully.

if currentValue.value == True:
path = "C:\LMP\EXTR2_PALL.bat"
import subprocess as sp
sp.call([path], shell=True)
system.tag.writeBlocking(['[default]PRECURE/GwayYes'], [True])
else:
system.tag.writeBlocking(['[default]PRECURE/EXTRE/REPRINT_PALLET'], [False])
system.tag.writeBlocking(['[default]PRECURE/EXTRE/REPRINT_PALLET'], [False])

This has successfully printed a label. Here's the batch file:
cd "C:\Program Files (x86)\LABEL MATRIX 2021"
LMWPRINT /L="C:\LMP\EXTR2_X.qdf"
exit

My problem occurs if for whatever reason (printer is down, print program issue, database table design changed) the Gateway Event does not produce a label. It appears that the Ignition Gateway is expecting something from the server and not getting it. I can run the batch file by opening it from the File Explorer after the system seems to have frozen up and it will run and print a label. I have restarted the Ignition Gateway but that did not clear up the problem.

The only way to clear up the no-print problem is to reboot the server. This is not a viable option for production. My question: is there something I can add to the sp.call procedure so that the Gateway Event can be run again even if the printer is temporarily down, or is there something in the batch file I could add to give the Ignition Gateway the "all clear" even if a label was not produced?

bkarabinchak.psi · March 14, 2023, 7:18pm

Use the </> button to format code. So presumably it really looks like

if currentValue.value == True:
    path = "C:\LMP\EXTR2_PALL.bat"
    import subprocess as sp
    sp.call([path], shell=True)
    system.tag.writeBlocking(['[default]PRECURE/GwayYes'], [True])
else:
    system.tag.writeBlocking(['[default]PRECURE/EXTRE/REPRINT_PALLET'], [False])
    system.tag.writeBlocking(['[default]PRECURE/EXTRE/REPRINT_PALLET'], [False])

Not directly related but some pointers on this I would recommend as someone who manages a few AntiDiversion lines that are all about tying barcode labels together - put the script that triggers a pallet label to print in it's own function in a project library script. Odds are you will probably need to call it from elsewhere, like you may need a "Reprint pallet label" button that triggers it again for events where it doesn't occur so the operator can do it.

Second, you are writing False to the same tag twice. Don't know if that's a intentional but you don't need to do that. If you mean two separate tags, then you can do that in a single call to system.tag.writeBlocking - the whole point is to write multiple tags to multiple values in a single line.

Toy our question though. You say that when something is down, like the printer or LabelMatrix software is down etc, it does not print, which I think is to be expected right? How could it otherwise. I don't think Ignition is expecting anything from the server here - calling subprocess just shells out the bat file but whether that succeeds or fails, Igniition will just continue onto your next line of code with the way your code is setup. You can get information out of the subprocess call, but I don't think that will necessarily help your issue here.

What tag is triggering this script, and what determines the value of that tag? My best guess of what is happening without more info on your systme is a pallet label is triggered to print, the currentValue.value is True, the batch file fails to run, and now that gateway tag that triggered the job is stuck on True. So it's not triggering the job again on the second or third attempt.

Third recommendation - add a logger. It's helpful for debugging this situation but also just in general, for any gateway events that are not required to execute as fast as possible, it's usually a good idea to put a logger in so you can see see the details of what ihappened when someone calls you up and says something went wrong 3 days ago.

Marc_Velazquez · March 14, 2023, 11:49pm

Thanks for the reply. Each workstation has it's own peculiar label so the project library is not useful for this, plus it's only a few lines of code. I did test the system and monitored the tag that calls for printing a label. After rebooting the server the Gateway Event worked properly and the tag would stay true and then turn to false once the shell(dos command) operations were finished. It is strange that the label would print yet the dos prompt stays up for at least five seconds when I run the batch file.

Regardless, I then broke the system by turning the printer off and sending another print request by the Gateway Event. The tag stayed true while the printer was off. I turned the printer back on and the tag (PALL_PRNT) still stayed true. I manually set the tag to false and ran the print request again. The tag went true but did not process the request. I put in an extra tag to see if the Gateway event was even getting past the first line but it did not go past.

Again I reset the Ignition Gateway but no effect. All during this time I can run the batch file from the server directly. I'm not sure where to put a logger in as the Gateway event never seems to fire after the system is broken. I again rebooted the server and after about 6 minutes of downtime the Ignition services came back up and connected with the projects. The print requests were processed successfully after the reboot.

if newValue.value == 1:
#if currentValue.value == True: 
	system.tag.writeBlocking(['[default]PRECURE/EXTRW/PALL_GETBY'], [True])
	path = "C:\LMP\EXTR1_PALL.bat"
	import subprocess as sp
	sp.call([path], shell=True)
	#print ( path )
	#system.util.execute
	system.tag.writeBlocking(['[default]PRECURE/EXTRW/PALL_LABEL'], [True])
	system.tag.writeBlocking(['[default]PRECURE/EXTRW/PALL_PRNT'], [False])
else:
	system.tag.writeBlocking(['[default]PRECURE/EXTRW/PALL_PRNT'], [False])

I tried the "newValue.value" to see if it would make a difference but it did not. I'm still stuck on the issue of the Gateway event not starting after it has had a problem completing a previous "job". It's as if it is not acknowledging any change to the tag since the PALL_GETBY tag does not change to true, as well as the lack of a printed label.

Marc_Velazquez · March 30, 2023, 7:08pm

It turned out it was not an Ignition or Gateway Event problem so much as it was a hung executable. The batch file I ran on the server runs LMWPRINT(.exe) so when there is a printer problem that executable stays as a task.

Once I cleared up the printer problem and then manually ended the task on lmwprint.exe, the label printed out and the system went back to printing normally for all of the other production stations. I will probably use a timer to launch a window for the operator to clear out the printer problem if a label does not come out within a certain amount of time, with a button to clear out lmwprint as well as set the trigger to tag to false.

So the lesson here is avoid calling out executables from script that run on the server since if they are not able to run then it will not allow that service/executable to run.