starting out

Brendan Dixon

Member
Join Date
Jun 2004
Location
Durban
Posts
3
ok, this is my first post here and have been doing alot of reading in the forums so most of you guys are the ones to talk to. I work for an egineering company in Durban, South africa. we have a few machines running PLCs and CNCs mainly from the Bosch range. I have been on a PLC programming course a couple of years ago. but at that stage we did not have the software to interface with the PLCs finally we have the software, but my memory has expired so without playing around to refresh myself, i am i bit stuck. i do not have the time at work and i do not have the software at home. what do i do.
 
programs are in list

Hi Thomas,

I have already read the learn PLCs section and it was informative indeed, but i alread know how PLCs work. My problem is for example, there is a bug in the program,to get the production going again as soon as possible i have the software,laptop, communications cable. etc. I have the program printed out in Instruction List and in the Bosch software. But i do not want to go fixing bugs when i am not fluent with how the programming is done. And the nearest other person that knows what is going on is 450 Miles away so it is expensive and timely to get the person here. so all in all. it takes us 2 days and
$1500 to get the person to do a 5 minute job. where if i could do it it takes just the 5 mins ? I do all the maintenance on these machines and it is my job to keep them running, but it is difficult when i only get to use the software like once a year or so, even though i am working with the machines every day.
 
I would play a bit if i were you

hi Brendon,

I would upload the program from the controler(plc,cnc driver,etc) and save it on my laptop, and then i would write code and download it to the device and see how they function and check if i still remember how they work :D :D


Just a thought.🍺



best regards.khalil
 
trouble

Hi Brendan
I`m sorry I didn`t understand you. It can be very dangerous changing a program. If you want to learn get you a plc and program on it to see how everything works. This way no ones life is endanger. When you say bug in the program, does the programmer actually change the program or is he just going online to see what`s happening and then tells you what to push to get back running? There is a big difference.
As far as programming I would choose the LEVER that says
LEAVE IT ALONE!!!
Do you understand what going online means? If not I can explain the simple stuff to you.
Good Luck!
Tom
 
my replies

Ok i know it the best way to get us another PLC and then play around with it, until i understand what i am doing. I am an experienced industrial electrician, and understand computers,electronics, etc very well. Am am not to familliar with programming as i have not spent much time on it. Sometimes the operator does something unusual that the programmer has not thought of and we usually end up waiting for the guy to come and connect to the PLC and find out where his fault is and fix it. I feel i can do this if i have sufficient knowledge and the tools. I have everything except the knowledge and do not want to do any "learning" on these machines as they cost
$4 600 000.00 dollars each.
 
ok then....

hi Brendan,

Then if i understand you well...you only want to revision what u have learnt in the past, the best way to do so (in my opinion), is to get your self a piece of paper(actually alot of paper) and write code lader logic is most commonly used for plcs these days i think, and try to imagine how you codes will take affect and if possible try to buy a micro plc and learn how to make ur codes do what u want...dont forget the tution on the top of this page ....

but you need time you can not practice without time...


I hope this help.🍺

best regards.khalil.
 
Breden,

There are two philosophies when it comes to Program Maintenance.

The first says, "It is what it is, so go with it!"
The corollary to the first says, "If it ain't broken, don't fix it!"

The second philosophy, my philosophy, is, "Look at it from the point of view of a reasonably rational Process Developer who understands program maintenance. If it looks goofy, BREAK THE DAMNED THING AND THEN FIX IT - RIGHT!"

The following complete description is aimed at the second philosophy.

However, if you aren't will or capable of going that far, the description will also support the first philosophy and its corollary.

Regardless of which philosophy you choose to follow, if you want to do this right, you have to put in the time to study and know your process and how the program controls it.

That means dissecting the process and the program and really learning how they work.

I would say, before even looking at the code, the first thing is to organize your understanding of how your process works physically. Try to classify major portions of the process in terms of "modules". That is, break the physical process down into a few (several?) basic, high-level, process-modules (these are usually not individual hardware components).

For example, a Punch-Press System might consist of a Loader, a Feeder, the Punch, an Extractor, a Stacker and a Wrapper. Each of those is a high-level process-module consisting of several hardware components (Outputs).

Then try to find the next level of modularity within those modules. Repeat this process until you are down to the actual output devices.

The purpose of this approach is to provide a simple, organized guide for yourself while you are trying to decipher the code.

Now, without using your guide, simply browse through your code and try to get a "feel" for how it is layed out.

If you have skeletons in your closet and/or you have been bad, then you'll probably be faced with spaghetti-code... without comments. (This is not good.) On the otherhand, if you've been very good, you might find well-commented, modular code. (This is very good.)

I'd like to say... "The odds are, the code will be somewhat well-commented and somewhat modularized." However, there are as many different ways to code a program as there are programmers... raised to the second?, third?, fourth?... power.

If you find that the code is organized in anything but "modular" form, then, until such time that you are capable enough to begin re-organizing the code, you are gonna have to maintain a hand-made (by pencil & paper, or word-processor) copy of the code.

You should organize this copy to follow your "Module Guide". Each rung that you enter on the hand-made copy should maintain the original rung number as it exists in the program.

The more "spaghetti-like" the code is, the more radical a difference you will find between the original code and your "organized" code. The more "modular-like" the code is, the less radical the differences will be.

At this point, I do not suggest that you simply make a copy of the program and re-organize it to follow the module-guide. If you do so, you will lose the current rung-relationship between the various rungs. Re-organizing a copy of the program, if it is necessary, will come later.

Once you have all of your hand-made rungs organized (with original rung numbers) to follow your module-guide, now you have to go into each section of code and find out how it "really" works.

This might involve reverse-engineering some of the logic, or breaking open the books to find out how a particular operation or function works. Sometimes, very low-level bit-manipulation is very hard to discern. Sometimes you have to BE THE COMPUTER, play the game through, and then see where the game leads.

One way or another, you have to crack-the-code and figure out how and WHY things actually happen the way that they do.

All the time that you are discovering how the damned thing actually works, you should be considering how the damned this SHOULD work!

At this point, you should have an understanding of how your process works and how it is controlled.

If you find that your code is reasonably well organized, then there is no need to go any further with the discovery/repair process.

On the otherhand, if you find that you have some degree of spaghetti-code (less than acceptable modularity), and you find it is objectionable (in terms of program maintenance), AND you find that you have the guts to re-write major portions of code...

...then, you need to make your plans. How can you introduce these changes with the least amount of interference on Production.

I do ALL of my process changes ON-LINE while the process is running.

I use a technique I call "Shadow-Code".

Shadow-Code is a duplicate of running code, albeit, in a different form. Shadow-Code does not control any actual Outputs. It does read all of the conditions that the current code reads plus any conditions that are unique to the Shadow-Code.

I include many "traps" and "monitors" to ensure that the Shadow-Code is doing as it should.

In those rungs that are intended to be replaced by the Shadow-Code I include a "switch-over-bit".

If I find that I am satisfied with the performance of the new code (Shadow-Code) I turn ON the "switch-over-bit". From that point on, the outputs are controlled by the new code.

I let the new code run for a few days before clearing out the old code.
 
Re: programs are in list

Brendan Dixon said:
it takes us 2 days and $1500 to get the person to do a 5 minute job.
For a one time expenditure of $1500 you may be able to justify the purchase of a 'spare' processor and some basic I/O to simulate your process on the bench. Even if you can't get enough processor to do the whole thing in one shot, at least you should be able to simulate/debug/rewrite short sections on a piecemeal basis.
 
Perhaps if you are working on a 4.6 Million dollar machine, the big guys could afford a few thousand to get you trained up.
If I see a machine coming that I am unfamiliar with I try to put the training cost straight to the capital project!!
 
I think if you have all the needed equipment then its worth getting online with the program and seeing what's going on.

For one, you may be able to pinpoint the issue by doing this. Additionally your programmer should provide you with a copy of the program that is fully documented so that you're not having to do as much detective work.

I think for someone who's lacking confidence, looking at the code run and figuring out the scheme will make you feel more comfortable with it.

At best maybe you gain the confidence to make the required changes or revisions that are needed. If you don't feel comfortable with that, then you can at least point the programmer to suspect areas, and he can make the revisions and send you the revised copy and you can update it.

Either way you'll get some experience, and maybe the next time you can handle it yourself.
 

Similar Topics

Hi, I am attempting to turn on an output for one second, every thirty seconds, but am having some trouble. I have a XIC with S:1/15 (first pass)...
Replies
9
Views
551
Rather new to structured text. I'm trying to edit a machine so that it will reinitialize with some push buttons held in for 10 seconds. Pushing...
Replies
13
Views
2,702
Hi Guys, I'm using an ABL33ER with Panelview 600. I have datalogging running on the HMI using the view studio datalog model on startup of the...
Replies
4
Views
1,097
Hello guys, I have windows 10 on virtualbox guests and not on the host. On a windows 10 guest I have TIA Selection tool V2022.06. When I...
Replies
1
Views
1,474
Hi This message popped up when I created a new hard disk (image) (TwinCat IO Server. TwinCat is not starting because of an invalid device...
Replies
3
Views
1,472
Back
Top Bottom