[swarf_rat]

There are probably very few people trying to do this, but I have my Mac talking to my Bridgeport S1 with TNC 151B. Works like charm.

Running Heidenhain TNCserver on Windows XP on top of Parallels Desktop on top of OS X 10.4, using a Keyspan USB-serial adapter with drivers on the Mac side talking to Windows through a serial socket emulator called SerialClient. Hardest part was figuring out which buttons to push on the control - I had to actually read the manual.

Now if I could just figure out how to save the machine parameters....

[awemawson]

With all those layers of software running, it's lucky the TNC151b only runs the coms port at 9600 !!!!


To save the machine parameters see this thread:

http://www.cnczone.com/forums/showthread.php?t=34680

[swarf_rat]

Andrew, thanks once again! Don't know why thread didn't show up in my search.

I had trouble uploading the parameters (always stopped at MP87) and larger programs (I was using an example you sent me, always stopped on line 115). It would download fine. Kind of looked like a serial com issue, but odd that it happened always at the same place. Also it would work OK in ME mode at 2400 but not FE mode at 9600.

Anyway I switched from the Keyspan to an IOGEAR USB-serial converter (which also has a different driver) and now uploads and downloads work flawlessly in FE mode.

In this setup the serial port data is piped through a serial socket emulator so you can watch and log the data as it goes by: makes you realize just how slow 2400 (and 9600) baud communication really was back when they were still using it!

[awemawson]

Hey, you think that's bad - my first introduction to computers was arround 1968 when I was sat at a Teletype on line to a timesharing bureaux at 110 baud on dial up, programming in Fortran ! And that was FAST compared to the labs HP desktop computer that sat and thought a long while before it spat the answers out <G>

AWEM

[swarf_rat]

So I made a nice new cable to replace my hacked up one thinking my problems were over. Suddenly the same com problems appear again. Switched everything back, still problems. I think I solved it though:

As of version 05 of the TNC software, they don't use DC3 (otherwise known as Xoff or ASCII hex 13) for flow control. This is hidden in the B rev installation manual where it is stated that ACK/NAK are used. However they normally aren't set up for hardware handshake either, RTS looped back to CTS, DTR and DSR etc. Part of my problems were due to not making all of these loop back connections in the cable - usually in a software handshake protocol the driver/hardware can ignore these things, but not in this case. My swapping of the USB-serial converter was a red herring, behaved differently perhaps due to driver differences or operator error but still did not work when set up the same way.

After wasting some time with an oscilloscope looking for noise issues (all signals look very clean) I started sorting through the serial protocol and looking at the serial log.

I had software handshake turned on in the serial port settings, which normally means Xon/Xoff are used for flow control. What the protocol does is send a block, followed by an ETB character, then a hex checksum, then a DC1 (Xon) character. The response is ACK (hex 06, block was received OK) or NAK (hex 15, block error). If ACK the next block is started, if NAK the block is repeated up to three times, then it gives up. The reason it was stopping at exactly the same place was that the end of line 115 in the test program resulted in a checksum of hex 13 (Xoff or DC3) and that stopped the serial interface. It was stopping at MP:86 in dumping the machine parameters because that was the first instance of a checksum of hex 12 (DC2 or tape character) which also stops the interface. Solution was to turn off software handshake. It is still a software handshake, but not the standard version recognized by the serial driver/hardware.

It is a bit more complicate in my Mac/Parallels/Windows/SerialSocketEmulator/USB-serial converter because the Windows serial port settings are kind of ignored. Or rather they are accepted regardless, the hardware actually being controlled by the serial socket emulator. A peculiarity being that for example, ME com mode can be set to 9600 baud, the socket set to 2400 as required by the control and it all works fine: data flows out of TNCServer at 9600, is buffered by the socket emulator, and passed to the control at 2400. Only thing is TNCSever thinks it is done way before the control has finished receiving.

I warned you it was esoterica.