The Sequel - Oh Blimey I bought a CNC Lathe (Beaver TC 20)

[PekkaNF]

Have you tried with one to max 1,5m long serial cable without any extras. I remember having same sort of problmes with long cables or faulty adapters. Laptops strugle with RS-232, their serial port buffer hardly never goes very negative, often it is even under -5v and any troule with cable is diaster. I never used flat cable, it was short shilded cable or I could not even get it to connect.

Another thing is that all the old Siemens programs configured the port in the S5 application program, if you didn't have the serial port on COM3 (from my memory) - tough luck and you have to do some fuckery in the BIOS. I did not touch that, I let others who thougt they knew.

Then again Sinumerik might be different on that one too.

Pekka

[awemawson]

Pekka I agree about flat cable - I'm only using it in a temporary adaptor set up for the analyser. (Though Siemens use about 1.5 meters of the stuff to link the X121 RS232 port on the CPU card to the socket on the operators panel.)

The cable I've been using in the main is the one that I can happily load the 820T from and also dump back ups - usual screened RS232 stuff.

Guests for lunch today so not much will happen, but I've ordered one of those gizmo's that Moray linked to, along with a MAX3232 board to convert RS232 / TTL. It looks a generally useful bit of kit at a very low price. It hopefully will let me more easily see character length to find this framing error thingy. Trying on a conventional 'scope is a pain as the triggering is inconsistent (as is the data I'm looking at).

This version of STEP5 has a drop down box to select which COM port to use - lucky as I only have COM2: available, but the silly thing is that the bit where the com port is selected doesn't have anything to select the ports parameters.

One has to remember this program was written in an age when expectations were far less, and things have moved on considerably since then in terms of usability.

[awemawson]

A bit of progress, but I've been delayed by moving a manure heap and reseeding more ground, to say nothing of still fighting the fly plague

OK Moray kindly pointed me at a cheap 'logic analyser' that would let me capture signals between the STEP5 program on the Toughbook, and the Siemens 820T controller. But these signals are at RS232 levels and the analyser is expecting TTL levels.

No big issue - either make or buy a converter based on the MAX3232 chip that does precisely this conversion. So, the USB analyser, a MAX3232 board, and some 9 pin IDC plugs and sockets ordered, all of which came to hand yesterday.

The MAX3232 board needs a 5 volt supply, so I modified a USB cable to give me this, and made up a short  Male, Male, Female adaptor cable for the 9 pin Toughbook serial port to allow connection to the converter card as well as onwards to the 820T controller.

First I set it all up just transmitting from the PC using the "COPY CON COM2:" command in a DOS box, and sure enough up it came on the analyser.

Then I tried connecting the serial port onwards to the controller, but no way would it go 'on line' Much chasing about then it dawned on me, the little MAX3232 pcb has one "RS232 to TTL" and one "TTL to RS232" port connected (the MAX3232 has two of each) - what I wanted, as I was just monitoring the interface, was a pair of "RS232 to TTL" converters. What was happening was that the RS232 output of the PCB was in parallel with the RS232 output of the 820T controller and clobbering it 

Oh well, best laid plans of men and mice . . . . etc !



Frustratingly the PCB was laid out such that there was no realistic way of using the other port on the MAX3232, but I have found another version, a "Sparkfun BOB-11189" that doesn't embody a 9 pin Sub D, but does bring out all the inputs and outputs to accessible places - one on order from Farnell.

But what I HAVE manged to confirm, is that the STEP5 PLC monitoring software is definitely altering the COM2: port settings to 'Even Parity' each time it is run, and thus generating the 'framing errors' as the controller expects 1 start bit, 8 bit data, no parity bit, 2 stop bits ie and 11 bit word, but it is getting a 12 bit word with even parity !!!! No idea how or where, and still seeking enlightenment 

. . .so that's the current 'state of play'

[awemawson]

A tiny bit more progress, (or probably more confusion), I've been pointed to an '.INI' file buried deep in the file structure of STEP5, that holds settings for all the COM ports from 1 to 6.

Sure enough it had EVEN for the parity bit for COM2: that I am using. I edited it to 'NONE', ran the program, and it STILL sets it up as EVEN parity 

. . . my head hurts !

[russ57]

Did you also use mode to set what you need? Clearly some very odd interactions between all the bit players in this drama.

If only they would exit stage left and leave the main characters to read the script...

I would think, as a last resort, you could set an arduino or similar to act as a protocol converter.

Last thought

Can you reinstall using the new ini file? It may just use it to set some run config when it is first installed /configured


Russ

[awemawson]

Russ,

I've set the COM2: to what I believe I need using MODE, run STEP5 then (exiting STEP5 first as otherwise it still has hold of the COM port) then typing just MODE COM2: to see what it's set to find that STEP5 has modified it yet again 

Yesterday I thought, OK, that's what STEP5 seems to want, so (contrary to the instructions) set the Siemens 820T controller to those settings and see what happens. It will still go on line but locks up as before.

All very intriguing, rather headache provoking, but never the less interesting. I wish I could have a few hours solidly 'at it' but things keep getting in the way !

I just hope that PK is having more success and less headaches down under - not heard from him in a while. 

[russ57]

Hopefully then the controller is not as stubborn in the parameter department as step 5...

Russ

[awemawson]

The really frustrating part is that this same RS232 link is used for uploading and downloading programs to the controller and works fine.

STEP5 was originally written I believe for CP/M where you had far better direct access to hardware than Windows lets you have.

This of course is a distraction from a detour from a diversion on the way to trying to solve the 'Spindle Orientation' issue, and although I'd love to be able to poke around in and maybe re-program the PLC it wasn't an objective that I chose!

I'm getting closer to being driven to load the PLC program from the other (smaller lathe) and see if the spindle orientation works with that. But it would have to be done with the greatest care in case the axis etc are over driven. 

[awemawson]

Farnell, good to their word, delivered the alternative MAX3232 PCB - the 'Sparkfun BOB-11189. So grabbing the soldering iron I quickly connected it up to a female 9 pin-D-Type and set the Logic SALE-AE analyser. Sure enough we can now go on line to the 820T and listen to BOTH sides of the conversation.

No time at the moment to go into it much deeper, but here is my first screen shot showing the transmission from the STEP5 port and the response from the 820T controller - need a bit of quiet time to dig into it further.

[awemawson]

This morning I set off with the good intention of getting STEP5 to start downloading block "FB11" and timing with a stop watch when it failed (this is the block that previously had consistently given "Last Segment Not Completed") My intention being to monitor with the Logic Analyser and look at the interactions at about the time of the failure.

To my great surprise the block down loaded error free !

OK on a roll I decided to download the one other block (PB202) that previously had locked everything up and caused STEP5 to crash the operating system - sure enough it whistled through error free - very very odd. I've left the interface settings as STEP5 has modified them on the PC, but the 820T controller is still set up 'as was'

So PC set to  9600/Even Parity/8 data/2STOP/XON=off/CTS=off/DSR=off/DTR=on/RTS=on
  820T set to  9600/No Parity/8 Data/2 Stop/XON=on/CTS=off/DSR=off/DTR=off/RTS=off

No idea why this is now working - but it is!

But the very odd thing is that when I look at the various 'Program Blocks' and 'Function Blocks' there is just not enough 'meat' in them to be the complete PLC program - the only block with any substance is the one that seems to control the 'W-Axis' which is not even used on this lathe.

So something is missing somewhere - there must be a back door into this PLC thingummybob that I've not found.

[WeldingRod]

You may have changed the loading on the rs232, which could be helping some sort of voltage/reflection issue...

Sent from my SAMSUNG-SM-G891A using Tapatalk

[awemawson]

To illustrate this conundrum I'll post some screen shots of some of the blocks in the PLC as downloaded by STEP5

First the Directory - (it was one line longer than a screen so I cut and pasted it !)

Then OB 1 which is the entry point for the program
Then OB 2 which is called on interrupts (and only seems to call the FB 99 W Axis routine)
Then PB 202 which should be the main program block
Then a couple of function blocks (FB11 & FB 60 as examples of 'no meat'
Then FB 99 the W axis service function that isn't used but is meaty !!!


There just HAS to be more to the program than this trivial bit 

[mc]

PB202 looks very suspect, given it should be far longer compared with the rest.

The thing that stands out to me, is what's the significance of the Segment 1 on all the screens?
Is there some way to access more segments?

[awemawson]

Yes it's very odd Moray, and try as I may I can't at the moment see any way of getting further segments.

Looking at the guide to programming the PLC most, but not all, of the FB function blocks listed in the PLC directory are standard ones that do things like transferring data to and from the PLC and NC parts of the controller.

It all looks pretty shell like and empty if I'm honest, and it's really odd that the one FB that looks OK to my untutored eye, is FB_99 for the non-existent W-Axis.

I'm trying to formulate a concise but meaningful question for the Siemens forum about this - they are an odd lot, and the moderators tend to kick things into touch if you are not careful how things are phrased and ramble too much! It's a question of getting all the graphical information into the single picture that they allow !

When the controller is loaded from an empty state you start loading NC Data and PLC Program and data, but then there is an 'ASM' file that no-one can explain what  it is, but I strongly suspect that it is compiled assembler code - the only reference to it I've found calls it a 'dump of user memory'.

I'm tempted to do a reload without the ASM file, and try and go on line to the PLC and see what's in it. If the ASM file IS compiled  assembler code for the PLC then surely the PLC program has to hook into it to use it at various points, and I see no sign in the 'Blocks' I've downloaded.

It's no tiddler at 207Kbyte and takes 30 mins to load !

[russ57]

Can you open the files out of step5 - notepad++ maybe - and compare the contents, at least for size?


Russ

[awemawson]

Russ that's a good suggestion but one I've failed to accomplish 

The original file that it seems to be writing to was named "820T@@ST.S5D" - (I say seems to be writing to, my only real clue is the date and time stamps on the files).

I've downloaded it to my desktop PC (remember that STEP5 is running on a Toughbook CF-52 under Win XP) and had a look using 'Hex Editor Neo' which lets me display in plain ascii text, hexadecimal or binary. Sure there are areas where a bit of recognisable text appears but the overall structure is still not clear (to me at least)

I've renamed it as a 'TXT' file so that I can attach it to this post - maybe others will have more success than I 

[awemawson]

Well progress   


Sometimes things are far simpler than you think, I've just been given a tip by a chap on the Siemens Forum that to see the other segments PRESS THE PAGE DOWN BUTTON   

. . . . 

If I get time tomorrow I'll experiment and see what I can see and post progress, for now I've just popped out to the workshop to prove the theory and it works - lots of segments.

[tom osselton]

That is good news!

[russ57]

I hate intuitive interfaces....

Russ

[russ57]

Or, 'intuitive' interfaces to be precise



Russ

[awemawson]

It turns out that the one 'Program Block' PB202 has 172 segments full of all sorts of complexities waiting to be de-coded. (But all the other blocks are 'single segment')

Below is a random but not untypical segment, segment 92 displayed in 'Ladder Format'.

Todays job is to try and find how I can get the graphical representation of the whole 172 segments into a readable file or out to a printer. Taking screen shots, or as I've been doing this morning actually photographing screen images isn't really practical to get to grips with this beast.

 STEP5, being from the era that it is is expecting a printer on a LPT port - well it's out of luck, because even if I had a suitable parallel connected printer the Toughbook hasn't got an LPT port.

It's running under XP professional, but won't use XP's default printer (an HP Laser on my network) although XP is happy with it.

More questions to the Siemens forum coming up I think!

[awemawson]

Well I've discovered a STEP5 utility that takes a file generated in STEP5 and allows it to print on the default windows printer - so that's one more hurdle straddled 

It's all very clunky, and all data for printing has to be put into an '.INI' file and an off line utility run - most peculiar !

But although I can cheerfully print directory listings of the program elements (Program Blocks, Organisation Blocks etc) at the moment I cannot find how to print the contents of the blocks themselves despite being able to see them on the screen. It surely MUST be possible, it's just I'm being dense I suspect 

I can even print out cross reference tables of all the inputs and outputs to the PLC program, but not the actual code or ladder logic - very odd, but this whole PLC escapade has been very odd so why should it change now 

[awemawson]

A VERY nice man on the Siemens forum has offered to take my STEP5 project file and turn it into a PDF of the ladder logic, so I've just zipped it up and posted it on the forum.

Meanwhile, looking through the code for the W-Axis (which isn't fitted to my lathe) I can successfully map the output "Q bits" in the PLC code to the input  bits on the circuit diagram that I have. This is encouraging - if eventually I can do the same for the M20 preparation code for Spindle Orientation that started this particular investigation what seems months ago, then I'll be a very happy bunny 

[AdeV]

Is this "ladder logic" what you and I would more generally know as the G-codes which form the program? Or is this something else? Am I likely to have to learn all this stuff for my Mazak, if I ever get it going? 

[awemawson]

Ade,

No, a long way from G code !

PLC's or Programmable Logic Controllers evolved to eliminate the masses of relays found in many automation systems as they were a constant source of failure, were expensive to build and fault find.

Consider the PLC like an electronic ULA or uncommitted Logic Array, that has loads of inputs, loads of outputs, and is programmed to define the logical connections between inputs and outputs.

The PLC goes one further step and can incorporate timers, latches, and interrupt service routines.

Now there are several ways this logic can be portrayed. In my view the simplest is the 'ladder logic'  with decisions shown as open or closed switches. You have such a ladder of contacts in your Bridgeport Interact for the 'eStop Chain' where the ultimate end point is to open the eStop relay if things aren't safe.

'Ladder' because the original relay logic contacts were strings between the positive and negative rails of the supply each string making effectively one decision, and when drawn out looking like a ladder!

Below is a slightly more complex bit of my PLC ladder (Segment 92) where an RS Flip flop is involved :

Flag bit 47.2 sets the RS flip flop if Flag bit 142.2 is True
Flag bit 47.1 clears the RS flip flop if Flag bit 142.2 is True

And the resulting output of the flip flop is presented to the interface as output bit Q0.2 which on my lathe is an actual hardware output 'Chuck Low Pressure Select'

(it equally could have been another flag bit to be used as input on another rung of the ladder)

I've no doubt that ultimately Flag Bits 47.2 and 47.1 will be derived from decoding M codes (or machine control codes) in the running program but I've not got there yet !


. . . niffty eh