Multiple printers on workstations being replaced by Accuterm PCs

[Steven Davies-Morris]

Here's my problem.

For years my D3-based point of sale system for drycleaners has used
Esprit network terminals and before LANs it was Wyse terminals. The
stations have always had their own local printers. One Epson thermal
TM88 for customer tickets (serial). Stations used for the markin of
clothes also have a parallel port Epson U220 tag printer, sometimes two.
If they have two it is on a switch box that operators manually toggle
between, but that is rare and if we had to give that up it would not be
too much of an issue.

Our Pick/BASIC clothes markin application has up to now printed a
thermal ticket out the serial port accessed via escape sequence, then
the tags out the parallel port (again an escape sequence toggle), then
finally the markin app issues a return to normal CRT operations with a
third escape sequence. All fine and dandy except that we cannot buy the
Esprit network terminals any more and must go to very small footprint
PCs using Accutern to talk to our local in store D3 servers.

I see in Accuterm that I can define one printer. What I need to be able
to do is plug in my serial thermal and my parallel tag printers, or if
necessary access them via USB ports with USB to serial and USB to
parallel converter cables. I am at a loss as to how this is done in
Accuterm. Anyone got any practical ideas? Anyone done this? Or got
another solution. I'm not concerned what technical hoops have to be
jumped through, but I do have to have a solution that provides the
functional equivalence. I'd like to get well ahead of the curve on this
so I can replace stations as they reach end of life without looking like
a doofus in front of my customers by not having a working solution.

I'm open to buying a software solution to sit between Accuterm and the
Windows printer connections if that is the answer.

I'm also open to hiring contractor help to get this done.

Cheers, and thanks for being here as a resource.
--
SDM a 21st century schizoid man in SoCal
Systems Theory website www.systemstheory.net
Through The Looking Glass radio show at www.deepnuggets.com
Email "The Cleaner System" at cleaner...@yahoo.com

[David Knight]

Hi,

I'm not an Accuterm guru; but at a simplistic level I would expect *any* software like Accuterm and others to emulate everything of the terminal it is pretending to be including routing data to a serial port or a parallel port; exactly as if you have a real terminal there.

So I guess I'm saying you may be barking up the wrong tree looking at printer setups within Accuterm? I'd be looking more at the emulation ability of the terminal definition to see if it supports the escape sequence to route data to COM1: and LPT1: etc? It's been a very long time; but I think that will work PROVIDING the PC does not have any printer drivers installed that want to grab COM1: or LPT1:

An alternative method would be to print to the printers from the server, which means setting each & every printer onto the LAN, and creating printer associations using NTPrinter [I'm assuming d3/win here] in the coldstart. Your app would then print like any other databasic routine.

A second, similar alternative is still to put the printers on your LAN but use Rasmussen's Printwiz service installed on the server; which is a huge, complex and extremely functional piece of software. In brief, your app would write out a data packet to a known server directory which Printwiz is monitoring. Printwiz, according to rules you setup would then grab that file, interrogate it, reformat it & turn it into a 'real' Windows print job that then prints to the Lan-based printer. Rather neat as you can get Printwiz to do all sorts of sexy things that are too darn hard to do inside databasic [I'm lazy]; such as graphics, barcodes, labels, overlays, colour etc.

HTH

[CDMI - Steve T]

Steven:

we used AccuTerm with our POS environment and had similar scenarios. i would not ask the 'terminal' to do the printing (nowadays). I would go the network LAN way if you can get IP based printers that work for you. IP based printers can be asked to print from any computer on the network.

I am a PICK consultant and would be happy to discuss your alternatives.

 

Steve Trimble (501) 615-8674

Computerized Data Mgmt Inc (CDMI)

---

From: Steven Davies-Morris <sda...@systemstheory.net>
To: mvd...@googlegroups.com
Sent: Monday, November 23, 2015 9:36 PM
Subject: [mvdbms] Multiple printers on workstations being replaced by Accuterm PCs

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+unsub...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Art Martz]

I remember a few years back using a parallel to serial converter in a
similar situation. It worked pretty well. I was using Ubuntu on the PC
though.
Art

[Bob Rasmussen]

I've read several responses to this, and though I appreciate the plug for
Print Wizard as an alternative solution, what you are proposing is quite
feasible. Have you asked Accuterm's tech support for help on this? Peter
has always been quite responsive. I know Accuterm supports passthrough
print at various levels; I don't know whether it supports multiple
channels.

Note, by the way, that the control sequences you must send for "printer
on", etc., will vary by the terminal type you are emulating. They'll be
different for Wyse60 than for VT320, for instance.

If you can't make Accuterm work for you, you might consider AnzioWin, our
terminal emulator. It supports output-only serial (aux), input-output
serial, output-only parallel, multiple device port switching, host control
of baud rate, device-independent printing, barcode generation, and more.
For more information about point-of-sale use, see this document:
http://www.anzio.com/resources/using-anzio-counterpoint-pos-systems

> --
> You received this message because you are subscribed to
> the "Pick and MultiValue Databases" group.
> To post, email to: mvd...@googlegroups.com

> To unsubscribe, email to: mvdbms+un...@googlegroups.com

> For more options, visit http://groups.google.com/group/mvdbms
>

Regards,
....Bob Rasmussen, President, Rasmussen Software, Inc.

personal e-mail: r...@anzio.com
company e-mail: r...@anzio.com
voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
fax: (US) 503-624-0760
web: http://www.anzio.com
street address: Rasmussen Software, Inc.
10240 SW Nimbus, Suite L9
Portland, OR 97223 USA

[Richard Wilson]

Accuterm still works with the old local printer logic for printers tied directly to the workstations



Rich

-- 
Richard A Wilson
Lakeside Systems
Smithfield, RI, USA
Voice 401-231-3959
Fax   206-202-2064

[Steven Davies-Morris]

On 11/24/2015 12:00 AM, David Knight wrote:
> Hi,
> I'm not an Accuterm guru; but at a simplistic level I would expect *any*
> software like Accuterm and others to emulate everything of the terminal
> it is pretending to be including routing data to a serial port or a
> parallel port; exactly as if you have a real terminal there.
>
> So I guess I'm saying you may be barking up the wrong tree looking at
> printer setups within Accuterm? I'd be looking more at the emulation
> ability of the terminal definition to see if it supports the escape
> sequence to route data to COM1: and LPT1: etc? It's been a very long
> time; but I think that will work PROVIDING the PC does not have any
> printer drivers installed that want to grab COM1: or LPT1:

This is new for me. At this time we have no PCs being used as POS
stations. But we are clearly going to have to deal with this very soon.
The store managers have a Windows PC for email, spreadsheets, etc.
Any Accuterm (or other terminal emulating) PC we install to replace an
Esprit network terminal will have no other printers attached or drivers
installed. The existing Esprit network terminal in use has the thermal
ticket serial printer on COM2 and the parallel tag printer on LPT1
respectively. It's a SLAVE.ON / SLAVE.OFF situation with the ESC
sequence to toggle the COM2 or LPT1 port printing.

> An alternative method would be to print to the printers from the server,
> which means setting each & every printer onto the LAN, and creating
> printer associations using NTPrinter [I'm assuming d3/win here] in the
> coldstart. Your app would then print like any other databasic routine.
>
> A second, similar alternative is still to put the printers on your LAN
> but use Rasmussen's Printwiz service installed on the server; which is a
> huge, complex and extremely functional piece of software. In brief, your
> app would write out a data packet to a known server directory which
> Printwiz is monitoring. Printwiz, according to rules you setup would
> then grab that file, interrogate it, reformat it & turn it into a 'real'
> Windows print job that then prints to the Lan-based printer. Rather neat
> as you can get Printwiz to do all sorts of sexy things that are too darn
> hard to do inside databasic [I'm lazy]; such as graphics, barcodes,
> labels, overlays, colour etc.
>
> HTH

Thanks for the suggestions. That sounds very interesting but it's
probably overkill for out needs. We're D3 Linux also.

[Steven Davies-Morris]

On 11/24/2015 06:43 AM, Richard Wilson wrote:
> Accuterm still works with the old local printer logic for printers tied

> directly to the workstations.

That's encouraging. I will try hooking up a serial thermal ticket and
parallel tag printer to a PC in the next couple of days and see if
Accuterm in Wy60 emulation does indeed support our existing mode of
toggling output via SLAVE.ON / SLAVE.OFF with the follow on ESC sequence
to send it to COM2 for the thermal and LPT1 for the tag. That would be
very nice because it would keep things exactly as they have been for my
customers. I will also contact tech support for Accuterm to see what
they have to say.

[Steven Davies-Morris]

On 11/24/2015 05:34 AM, CDMI - Steve T wrote:
> Steven:
> we used AccuTerm with our POS environment and had similar scenarios. i
> would not ask the 'terminal' to do the printing (nowadays). I would go
> the network LAN way if you can get IP based printers that work for you.
> IP based printers can be asked to print from any computer on the network.
> I am a PICK consultant and would be happy to discuss your alternatives.

> *Steve Trimble* (501) 615-8674
> Computerized Data Mgmt Inc (*CDMI*)

The printers we are currently using are the Epson TM88 thermals for our
tickets and the U220s for the tags. They are not IP addressable
devices. Tickets and tags are printed right at the dropoff / markin
stations. Thinking off the top of my head, going to IP based printers
would be doable by placing a little 4 port LAN hub at each station and
hanging the printers there. And of course getting IP addressable
thermal and tag printers. I am not opposed to that but it would be
further down my list of preferences in the short term. I do see long
term advantages in removing the printing from the stations since it
would mean we could use anything with a terminal emulation (or terminal
in a browser) to talk to the D3 server and not have to worry about what
methods of printing the PC/workstation/whatever supports. You will
definitely be hearing from me to have a chat WRT to my options. I will
keep it brief so I do not chew up your valuable time. :) Thank you.

[Steven Davies-Morris]

On 11/24/2015 05:49 AM, Art Martz wrote:
> On 11/23/2015 10:36 PM, Steven Davies-Morris wrote:
>> Here's my problem.
>>

>> Cheers, and thanks for being here as a resource.
>>
> I remember a few years back using a parallel to serial converter in a
> similar situation. It worked pretty well. I was using Ubuntu on the PC
> though.
> Art

I'm open to using Ubuntu desktop PCs in lieu of Windows. In many ways
that would be preferable. I've just built a Raspberry PI box that runs
Ubuntu. It has 4 USB ports. A few hoops to jump through but in theory a
Linux based terminal emulator on it might do the trick with one USB to
serial converter and one USB to parallel converter. Provided it can
route to COM2 and LPT1. Definitely something to look into as a possibility.

[Steven Davies-Morris]

On 11/24/2015 06:32 AM, Bob Rasmussen wrote:
> I've read several responses to this, and though I appreciate the plug
> for Print Wizard as an alternative solution, what you are proposing is
> quite feasible. Have you asked Accuterm's tech support for help on this?
> Peter has always been quite responsive. I know Accuterm supports
> passthrough print at various levels; I don't know whether it supports
> multiple channels.
>
> Note, by the way, that the control sequences you must send for "printer
> on", etc., will vary by the terminal type you are emulating. They'll be
> different for Wyse60 than for VT320, for instance.
>
> If you can't make Accuterm work for you, you might consider AnzioWin,
> our terminal emulator. It supports output-only serial (aux),
> input-output serial, output-only parallel, multiple device port
> switching, host control of baud rate, device-independent printing,
> barcode generation, and more. For more information about point-of-sale
> use, see this document:
> http://www.anzio.com/resources/using-anzio-counterpoint-pos-systems
>

Thanks for the response, Bob. I will definitely contact Accuterm
support since that is what we have on the manager's PCs. But we aren't
wedded to that. For the replacement POS workstations I would be more
than happy to use AnzioWin if it does the job we want with a minimum of
fuss (or "changes in the customer's environment"). I will read the
document you linked today. Cheers.

[Pete Schellenbach]

Hi Steven -

While AccuTerm only supports a single slave-print device, you can use a script to change the name of the printer used for that device. The standard slave-on and slave-off codes work fine. We have several VARs with POS packages who attach a pole display and access it as a slave printer. You need to set the slave print mode in AccuTerm to "text" in order to pass printer control codes and escape sequences to the printer. Otherwise these go through the Windows printer driver and get ignored. If you search the AccuTerm support forum (forum.zumasys.com) for "display pole" you should find some examples.

Thanks,

Peter Schellenbach

[Steven Davies-Morris]

Oh Pete! Thank you so much for this information. My next stop in this
process will be the zumasys forum. I will be looking into testing this
ASAP with a bare bones PC, Accuterm and one of each printer. I was
having a very nasty reaction in my gut as I thought about this problem
and how to handle it. I'm not keen on on sticking Windows PCs into Dry
Cleaners as POS stations (a very unfriendly environment at the best of
times) but realize the days of dumb network terminals are behind us.

Cheers.

--
SDM a 21st century schizoid man in SoCal
Systems Theory website www.systemstheory.net
Through The Looking Glass radio show at www.deepnuggets.com

[Tony Gravagno]

I agree with our colleagues. Everything about this problem screams LAN-addressable printers. They're small, inexpensive, mobile, no wires, and modern in exactly the way that dumb terminals are not.

About PC's and terminals, etc, I'm also thinking in today's world tablet devices are so prevalent and cheap that we should feel compelled to see how they fit in a modern topology. I don't just mean that users can drag a tablet around the workplace - that too. But it's a network-accessible device which can serve to coordinate others. Now, this is a half-baked idea so far, but as an example...

Picture a tablet just sitting somewhere around a workstation, under the counter maybe or in a desk drawer. With bluetooth an external monitor can display the screen, and a keyboard can be attached. So there goes the knee-jerk we all have about mobile devices having a small screen and even smaller keyboard. What I'm seeing here is that all of the components are modular, disconnected, easily replaceable, low-cost, and the technology is readily available to make it all happen. Your printer, keyboard, monitor, and "PC" are all isolated from one another, brand-independent, and yet they appear to work as a single unit, just like the old wired-up dumb terminal on a serial port with an aux printer. And even cooler - AccuTerm is available for Android so you may not need to do anything to change your BASIC UI code.

So when I wake up will any of this still make sense?

HTH
T

[Art Martz]

On 11/24/2015 11:19 AM, Steven Davies-Morris wrote:
> I remember a few years back using a parallel to serial converter in a
>> similar situation. It worked pretty well. I was using Ubuntu on the PC
>> though.
>> Art
>
> I'm open to using Ubuntu desktop PCs in lieu of Windows. In many ways
> that would be preferable. I've just built a Raspberry PI box that
> runs Ubuntu. It has 4 USB ports. A few hoops to jump through but in
> theory a Linux based terminal emulator on it might do the trick with
> one USB to serial converter and one USB to parallel converter.
> Provided it can route to COM2 and LPT1. Definitely something to look
> into as a possibility.
>

I used gnome-terminal in ansi mode. As I recall, I just setup a printer
printing to the COM port, and then used something to print to the print
que. I can't remember if it was an aux-print mode in gnome-terminal, or
something else, but the print job went to the que serviced by the
printer defined on the COM port. As I recall, it was a pretty much boot
it and forget about it type of application.
Art

[Steven Davies-Morris]

On 11/24/2015 09:45 AM, Tony Gravagno wrote:
> I agree with our colleagues. Everything about this problem screams
> LAN-addressable printers. They're small, inexpensive, mobile, no wires,
> and modern in exactly the way that dumb terminals are not.

Long term I agree.

> About PC's and terminals, etc, I'm also thinking in today's world tablet
> devices are so prevalent and cheap that we should feel compelled to see
> how they fit in a modern topology. I don't just mean that users can drag
> a tablet around the workplace - that too. But it's a network-accessible
> device which can serve to coordinate others. Now, this is a half-baked
> idea so far, but as an example...
>
> Picture a tablet just sitting somewhere around a workstation, under the
> counter maybe or in a desk drawer. With bluetooth an external monitor
> can display the screen, and a keyboard can be attached. So there goes
> the knee-jerk we all have about mobile devices having a small screen and
> even smaller keyboard. What I'm seeing here is that all of the
> components are modular, disconnected, easily replaceable, low-cost, and
> the technology is readily available to make it all happen. Your printer,
> keyboard, monitor, and "PC" are all isolated from one another,
> brand-independent, and yet they appear to work as a single unit, just
> like the old wired-up dumb terminal on a serial port with an aux
> printer. And even cooler - AccuTerm is available for Android so you may
> not need to do anything to change your BASIC UI code.
>
> So when I wake up will any of this still make sense?
>
> HTH
> T

I like the Accuterm mobile app. It works very well. Maybe next year
this ^^^ is something to tinker with.

[Steven Davies-Morris]

We've been very much fire and forget WRT to printing tens of millions of
transactions since 1990. Now I have an issue to deal with. I'll be
happy to solve that then go back to fire and forget!

--
SDM a 21st century schizoid man in SoCal
Systems Theory website www.systemstheory.net
Through The Looking Glass radio show at www.deepnuggets.com

[George Gallen]

You could get an Ethernet to serial converter. Digi is one we have used over the last 7 years. Or you always use something like a raspberry pi to receive the Ethernet and then send it use to serial/parallel.

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Tony Gravagno]

For this kind of application perhaps it's appropriate to consider QM running over Raspberry Pi.
http://www.openqm-zumasys.com/wp-content/uploads/2015/02/OpenQM-on-the-Raspberry-Pi.pdf
This would fit perfectly with the distributed architecture that I described, making the DBMS server itself just another low-cost and easily replaceable component.
The few challenges here would include:
- Porting D3 to QM: Though QM support for D3 nuances is quite good.
- Disk storage: How much data does a drycleaner store have? But heck you might be able to add a 4TB external drive via USB. :)

The more I think about this stuff the more I wonder if it's not time to radically reconsider how we do things in smaller environments.
We still centralize everything on a server like we did in the 80's: CPU, database, storage, ports, printing. The toplogy I've described with tablets, bluetooth, wi-fi, etc is completely in line with modern BYOD (Bring Your Own Device) challenges and solutions.

The only issue I see is that there's a matter of getting from here to there : Almost all of the apps we have in this industry are built on and for the server-based model. It's tough for people to re-think and then re-architect new topologies. I think this paradigm is more in line with new applications for new end-users in small installations. Now all we need are enterprising developers who are interested in targeting that audience. (I'll spare you a rehash of my views on that.)

But this isn't too far off from what I know people are doing now. For example there are companies in this industry (and you can talk up your own apps) that provide POS software where the POS workstation is a full PC, completely independent of the server just in case the main server or the network goes down. With low-cost, portable, easy to use and replace devices, this specific application could benefit a great deal.

And if you think about it, companies that produce restaurant applications are doing this already, with a tablet as the UI for wait-staff, transmitting orders to the kitchen, processing payments from the device, printing receipts on a network printer (or from the device itself). That paradigm is already well recognized but there aren't a lot of applications making use of it. There are opportunities here.

But to the original point, some of this starts with QM over Pi.

HTH
T




T

On Tuesday, November 24, 2015 at 8:19:33 AM UTC-8, Steven Davies-Morris wrote:

...  I've just built a Raspberry PI box that runs

[fwinans]

The original poster clearly works for a firm that _loves_ their old printers;  they've admitted they can't keep buying
the terminals that have enabled those printers, but they're still struggling to find a workaround to keep those
printers anyway.   Anyone that blithely tells them about neat new printers is going to get an earfull,  I can tell.

I'm often amazed at what all Accuterm can do, but this time I'm sceptical that any of the supplied emulations
are so detailed as to provide slave printing to both serial and parallel printer 'ports' on the emulated terminal,
as there'd have been scant call for this out in the overall marketplace.

And printers / terminals can have some pretty obscure quirks that means you can't just order some other
device out of a catalog and be sure it will be a drop-in replacement.  I almost choked when I saw in another
thread the opinion expressed that one just doesn't ever need local linux support, it can allways be done remotely. 
We've even gotten burned by later models by the _same_manufacturer_  altering their traditional handling of
formfeeds when the rendered page thus far has no visible printing yet, resulting in needless blank pages from
basic programs that relied on the old behavior.

[Tony Gravagno]

Well, first, I never speak in absolutes. (I love that line.) I didn't say here that one doesn't "ever" need something or that something can "always" be done. I'm saying it's generally not necessary. I've never seen a Linux fan in a forum saying something like "gee, it sounds like someone is going to have to go onsite to fix that problem". I've also never heard of a MV VAR from this "can't involve anyone else in my business" community who sells an application and then tells the end-user that they should get local OS support. Peripherals maybe, network probably. OS? Nah.

Also, you're talking about printer issues. Peripherals can present problems requiring onsite remedies, which is why I have never offered "full" system support to include serial ports, tape, or printers - and you also only see me rarely getting into related discussions in public. But my comment was on Linux, not hardware devices connected to it.

To your overall point, I agree. A small shop is not eager to endure the cost of a refit unless the long-term costs are expected to diminish. But once again, there are no absolutes. Changes like this need to be well considered, and reasoning needs to be clear and compelling for changes that are made. As much as we deal with technical issues, this is still a very people-oriented business that we're in, and technical decisions are highly subject to individual sensibilities.

T

[George Gallen]

Well, one option would be to have a raspberry serially hooked to the D3 . Have a program that monitors the serial in and if sees the aux on/off codes will start to feed it out to a sub to serial port to the existing printer, otherwise feed it a pipe which another program running is monitoring to display as its STDOUT.

The pi has a serial in/out pins, but you have to be careful to limit the voltage to 3.3v or you will kill the pi. 

However the USB to serial/parallel methods will have built in voltage regulators

Only issue would be if your using any screen control codes, not sure how you reflect those using STDOUT of a program running in a bash shell

This way the server and printer stays the same, just the terminal changes and the pi's footprint is very small. Use a HD tv as the monitor for the pi.

--