Programming in advance?

I work for a small company that is making its first foray into system integration. The whole project has been a mess. For example, my boss decided that since I attended PLC training, I should design the whole control system. I finally convinced him to hire a freelancer to draw the electrical schematics, but the project was already way behind at that point.

Now, as we wait for the control panel components to arrive, they want me to go ahead and begin programming the PLC before anything is even ready to run. I am reluctant to write the whole ladder logic before I can even test anything, especially since this is my first real project involving PLC programming. I prefer to test as I develop my program. Is it typical practice to write the program for a whole system before it is even ready to run?

hey no need hardware setup always , most of of the IDE have its simulator so u can simulate the logic in software also.

Yes. Usually the program is written or a majority of it is before the hardware is available. As mentioned simulators can help out a great deal.
Usually parts from older programs that are working can be used in the next project to help the development process.

Regards,

you really should convince your boss to hire a professional to do the coding but have him on site and look over his shoulder and be your mentor.

I am confident in my ability to do do the coding, I was just reluctant to do it without the hardware. We aren't even doing any offsite testing, all our testing is being done concurrent with the integration. If it's reasonable for them to expect me to have the program ready , I'll go ahead and write some logic, although I'm sure a lot of debugging will be necessary.

Briankr32 said:

they want me to go ahead and begin programming the PLC before anything is even ready to run.

Click to expand...

Here add it to the list

http://www.plctalk.net/qanda/showthread.php?t=105263

Briankr32 said:

I am confident in my ability to do do the coding, I was just reluctant to do it without the hardware. We aren't even doing any offsite testing, all our testing is being done concurrent with the integration. If it's reasonable for them to expect me to have the program ready , I'll go ahead and write some logic, although I'm sure a lot of debugging will be necessary.

Click to expand...

This is the trouble: if you don't have the hardware I/O configuration you can't do a proper I/O configuration in the program. In such cases I tend to set each I/O point to a bit (flag) and then define the I/Os later. However, as you said, there will be a lot of debugging involved ...

In my opinion, the most important thing is to have an accurate sequence of operations before you start writing code.
Without that information, you will certainly be changing a lot of code on site.
Just my two cents.

Briankr32 said:

I am confident in my ability to do do the coding,.

Click to expand...

With the most respect possible, you don't sound confident in yourself. As frustrating as it may be, most places put the cart before the horse. The only difference is how far in front of the horse the cart is, so yes, most programming is done without even having the hardware selected. You have come to the right place though, these guys have helped me through some deep water. Good luck to ya.

You certainly can start programming immediately.
Write the code with symbolic addressing. When the hardware design is finished all you have to do is to update the symbols.
You can also simulate your code (depending on if a simulator is available for the type of PLC).
This is a completely normal way of developing code.

I usually only write pieces of the final program before the hardware is here because our programs are small anyway (takes less than a day to write the whole thing), and because so much of it is dependent on Modbus comms with multiple devices. If I know and am familiar with the PLC and all Modbus devices for that project, I'll write the program ahead of time. Otherwise I like to hook everything up, power on, and get Modbus and all I/O working first.

IF (big IF) you're using a ControlLogix/CompactLogix system, then go ahead and write the code using tagnames (example: LEFT_START; RUN_RELAY; UP_RELAY; etc.) ...

once the wiring has been done (or at least drawn out) then you can come back and assign the tagnames as aliases for the real-world inputs and outputs ...

example:

LEFT_START gets assigned to Grinder:I.Data[0].5 and so on ...

(I'm pretty sure that this is what JesperMP means by "symbolic addressing") ...

ceilingwalker said:

With the most respect possible, you don't sound confident in yourself. As frustrating as it may be, most places put the cart before the horse. The only difference is how far in front of the horse the cart is, so yes, most programming is done without even having the hardware selected. You have come to the right place though, these guys have helped me through some deep water. Good luck to ya.

Click to expand...

ditto.

If you can't program the vast majority of the code with I/O layout and a process description, you are not ready to go it alone.

If you know how much I/O you will have then you can map the I/O to memory bits. and then write the logic with the memory bits.

Then when you get everything wired up, you just change the memory bits that the physical equipment is linked to. Logic stays the same, mapping just changes.

m0.0 = i0.0
m0.1 = i0.1
and so on.

full disclosure, I've never used this method, but I know a guy

Any Systems Integration work will require that you get started prior to final electrical design and component procurement. I've been on projects where it's taken a year+ to get the software ready for FAT. Certainly don't want to order hardware before it's even needed. Others have pointed out the aliasing trick, I am a IO buffer kinda-guy. I can pretty much do my final IO mapping just prior to commissioning and be good to go once onsite.

How large is this project? How many hours have you estimated it will take to program? 10? 100? 1000? PLC Training is NOT Systems Integrator training!

Smaller projects, sure you can just brute force your way through and just make it all work w/o much issue. But the larger the project, the more you have to design on paper, the more you have to simulate/test/debug. Often times you won't have the hardware so you need to come up with some plan to create a test environment. You can use virtual machines, emulators...etc. But to simulate you still have to write the code to allow this.

I am a huge proponent of creating device-level AOIs/Function Blocks as well as matching device face plates for SCADA/HMI. I am also a huge proponent of having a Structured/Standard method to programming. You can easily have 50% of your code standardized and this alone can give you full manual control and simulation ability of just about any system. The other 50% will be the logic required for the actual process you are programming for. But, you won't learn this with just "PLC training".