bernie_carlton
Lifetime Supporting Member + Moderator
Terry Wood's post in another thread reminded me of the programming contortions I encounterd.
Our mother company purchased a firm whose machines processed a product in parallel lanes. The lanes were independent other than that they were on the same machine. So lane 1's program was "See lane 1's inputs - turn on lane 1's outputs". Simple
The other lanes were simply copies of this logic with their own appropriate inputs, outputs timers, counter etc. Very easy to clone. The original machine had 4 lanes but when they went to 6 lanes it was no problem. Cut, paste, change references.
Then the real changes started happening. They were now processing a new type product, still in lanes, but of greatly variable size depending on the product. Now if it was product 1 you might use this set of inputs, but if it was product 2 dyou would use another set of inputs. Another part was the outputs. Where before a single output was turned on for a lane now a GROUP of outputs were turned on, again depending on the product being run.
So I wrote code before the main processing, selecting the proper inputs depending on the product being run (like Terry's NO/NC option) and presented the selected inputs to the lane processing as control relays. Likewise the lane processing, instead of setting actual outputs now set control relays which are interpreted in susequent sections of code depending on product type to turn on the appropriate group of outputs.
Once I had this done I thought - they can't make it much harder than that. Guess what, now the processing had to be able to run in one direction or the other. This meant the effective inputs and outputs were now swapped in order. So another layer of abstraction was placed before and after the code noted above. Now the 'product dependent' code operated not on real I/O but on control relays which were related to the real I/O dependent on direction.
In an AB SLC program the program files are in order, input direction processing, input product processing, lane code, output product processing, output direction processing. I'm just waiting to see what sales dreams up next.
Our mother company purchased a firm whose machines processed a product in parallel lanes. The lanes were independent other than that they were on the same machine. So lane 1's program was "See lane 1's inputs - turn on lane 1's outputs". Simple
The other lanes were simply copies of this logic with their own appropriate inputs, outputs timers, counter etc. Very easy to clone. The original machine had 4 lanes but when they went to 6 lanes it was no problem. Cut, paste, change references.
Then the real changes started happening. They were now processing a new type product, still in lanes, but of greatly variable size depending on the product. Now if it was product 1 you might use this set of inputs, but if it was product 2 dyou would use another set of inputs. Another part was the outputs. Where before a single output was turned on for a lane now a GROUP of outputs were turned on, again depending on the product being run.
So I wrote code before the main processing, selecting the proper inputs depending on the product being run (like Terry's NO/NC option) and presented the selected inputs to the lane processing as control relays. Likewise the lane processing, instead of setting actual outputs now set control relays which are interpreted in susequent sections of code depending on product type to turn on the appropriate group of outputs.
Once I had this done I thought - they can't make it much harder than that. Guess what, now the processing had to be able to run in one direction or the other. This meant the effective inputs and outputs were now swapped in order. So another layer of abstraction was placed before and after the code noted above. Now the 'product dependent' code operated not on real I/O but on control relays which were related to the real I/O dependent on direction.
In an AB SLC program the program files are in order, input direction processing, input product processing, lane code, output product processing, output direction processing. I'm just waiting to see what sales dreams up next.
