The Kermit Project |
Now hosted by
New York City USA • firstname.lastname@example.org
In this page we say "press" or "press brake" for convenience, but this can refer to any type of Cincinnati, MAG, or other machine that is controlled in the same way.
Cincinnati machines are connected to PCs via serial port with a null modem cable (explain) (search). The CNC program is written on the PC, downloaded to the machine's controller, and then possibly modified by the machine operator and uploaded back to the PC. Kermit software is used for this process in all machines manufactured since 1987, as you can see in this 2001 handout from Cincinnati Inc. YOU SHOULD READ THIS HANDOUT, and then read the rest of this page for corrections and supplementary information.
The Cincinnati handout discusses both MS-DOS Kermit and Kermit 95, and states that MS-DOS Kermit can be used on Windows 95 and NT. THIS IS NOT NECESSARILY TRUE. MS-DOS Kermit is not designed for, and is not supported on, 32-bit or 64-bit versions of Microsoft Windows such as Windows 95, 98, ME, NT, 2000, XP, Vista, or Windows 7 or 8 (details). If you are using MS-DOS Kermit on 32-bit Windows and have problems with it, you'll need to switch to Kermit 95, which is native, recommended, and supported on 32-bit Windows. This is especially true for Windows XP or later, where MS-DOS Kermit is increasingly unlikely to work at all. CLICK HERE to download a full-featured trial version of Kermit 95.
This page discusses common problems using Kermit 95 with Cincinnati machines. An unusual aspect of the Kermit/press connection is that Kermit is normally in server mode, so it can be controlled by a Kermit client on the press brake; some consequences of this fact are covered below.
Serial Ports and Modems section of the Kermit 95 FAQ.
The newer your PC or Windows version, the less likely it is to have a traditional "COM1" type of serial port (such as an 8250 or 16550A UART with a male DB-9 or DB-25 connector). Newer Windows platforms have all sorts of serial-port and/or modem substitutes or simulations that can't be accessed by the regular COM-port driver, sometimes they have nothing at all and you have search for a third-party USB-to-Serial adapter such as this one. These "non-COM" ports must be used through the Windows Telephony interface (TAPI); that is, through the name listed in the Phone and Modems folder (possibly just Modems, depending on the Windows version) of the Windows Control Panel.
Unfortunately, COM ports (or their modern substitutes) usually do not show up in the Control Panel Phone and Modems folder by default. If this is the case on your Windows PC:
Now when setting up Kermit 95, instead of using:
set port com1
set port tapi Communications_cable_between_two_computers
Even when you are using the appropriate driver (COM or TAPI), you still might need to make certain adjustments to communicate successfully:
But since Kermit is in server mode, deleting or renaming existing files is not allowed by default; that is, unless you tell Kermit it is OK. Thus if you follow the directions in the Cincinnati tip sheet for setting up Kermit and then try to replace a file, Kermit won't allow the original file to be disturbed, and therefore renames the incoming file to HANDLE.CNC.~1~ or whatever.
Kermit's options for filename collisions are chosen with the SET FILE COLLISION command. The default option is BACKUP, but that requires that the existing file be renamed. Another option is OVERWRITE, but that requires that the existing file be deleted. In either case, the server must be told to allow changes to existing files.
Execute these commands before entering server mode. Examples:
COM Port TAPI set flow none set modem type none set port 1 set speed 9600 cd /programs set file collision backup enable rename server set flow none set port tapi Communications_cable_between_two_computers set speed 9600 cd /programs set file collision overwrite enable delete server
This scenario has been reported on a Cincinnati Milacron Contour Tape Laminating Machine with Cincinnati Milacron Acramatic 975 Controller.Kermit 95 calculates packet timeouts dynamically, whereas MS-DOS Kermit uses a (user-specifiable) fixed timeout interval. Here is an initialization (or customization) file that you can use with Kermit 95 that should eliminate the problem. In this example, SET CARRIER-WATCH OFF is included because the serial-port cable only has three wires (i.e. does not present a carrier signal; see this page for information about cables and wires).
Explanation: When receiving a file, the Cincinnati machine buffers incoming data until the buffer fills up. At this point it “turns around” to write the data out to permanent storage, and this takes significantly longer than the normal packet turnaround. Since the previous packets were acknowledged promptly, K95 had adjusted its timeout to be somewhat lower than the delay that occurs at this point. When the expected acknowledgement did not arrive when expected, K95 retransmitted the previous data packet and evidently this confused the machine (although it shouldn't have). Perhaps when writing data to disk, it can't tolerate activity on the serial port. Anyway, telling K95 to use a somewhat generous fixed timeout cures the problem.SET PORT TAPI (or COM1) SET SPEED 19200 (or other) SET FLOW-CONTROL NONE SET CARRIER-WATCH OFF ROBUST SET SEND TIMEOUT 8 FIXED (or other number)
enable delete enable rename server