Host Engineering Forum
General Category => DirectSOFT => Topic started by: franji1 on March 08, 2008, 09:12:09 AM
-
I think we can all agree that more choices is always better. IEC-61131-3 specifies 5 different languages, but are they the best? Are all 5 needed? I could see something like SFC, ladder, and a BASIC/Structured Text type language being the most needed??? (this is my opinion, but I care about what YOU think!)
Choose as many languages as you think you truly need (less is more sometimes, though, so if you think 17 languages, including COBOL, should be running in your PLC, you may want to whittle it down :D)
If you don't see yours listed, choose Other and please post a comment as to which one it is. Also, feel free to comment on the pros and cons of the languages above!
-
I put my vote in for function block diagram language.
FBD is powerful and easy to program with, it makes expressing complicated logical relationships clear and concise. It is always interesting to me how 4 or 5 pages of ladder can be compressed into 1 page of FBD, and even though the representation is so much more compact, it is often easier to read and decipher the flow of control.
It is the one real tool I miss when using DirectSoft as compared to Honeywell, A-B, Modicon etc.
Oh, and being able to program in C or C++ wouldn't hurt my feelings one bit either. ;)
-
I put my vote in for function block diagram language.
After I ran this poll for a while, I noticed I mistakenly left out FBD (IEC-61131 Function Block Diagrams). Please, if anyone else likes FBD, please let us know here by posting something (you can't just vote "other" - I need to know what "other" is ;D)
Thanks cdudley for pointing this out!!
-
Function Block Programming has my vote. I think expanding the I-box would be nice. With the FBP you can copy and paste whereas with the I-Box you have to fill in the box each time.
-
I too vote for FBD. There are some very powerful functions in FB that would take several ladder rungs to perform the same. Plus, as mentioned, the ease of circuit comprehension at a glance.
-
I also would like to see FDB with the I-Box as mention by PLCGuy! FDB would speed up things.
-
If you're going to include Perl and Java, I nominate Python. I'm not sure I want to program a PLC in Python, but I sure don't want to do so in Perl, and if a language from that genre were to be available, I'd like Python. What the heck is Lua?
And, what do you consider the difference between Stage and SFC, since they're both listed? I always considered Stage to be a somewhat non-optimal implementation of SFC.
-
And, what do you consider the difference between Stage and SFC, since they're both listed? I always considered Stage to be a somewhat non-optimal implementation of SFC.
There are many differences between them. Both of them are based on Grafcet, and Petri Nets, but it's like C++ vs. Java. Sure, there are similarities, but you definitely have 2 different camps. Stage is definitely, exclusively a Koyo/ADC language, while SFC is a "standard" that is not PLC specific. Just want to see who likes Stage and who likes SFC.
-
SFC for me, please.
-
Don't you or Bob ever sleep? ;)
Bob - Bella - great movie! (I actually liked it more than Terry did!)
-
So yer sayin' yer a chick...and she's not? Hmmm...gotta think about that one. ;)
-
As long as there's one of each, it'll work out.
-
Well...I saw him at Blockbuster last night, and he was leaving with a movie that met all of the criteria for being a chick flick. I wished him well, and went home to watch Hell Boy. <insert Tim Taylor grunting here>
Since he liked it better than she did, one is left to reevaluate the starting condition. ;D I've known Mark for like...forever...and he is a bit of a softy though.
-
Oh, I should have qualified my comment. As long as there's one of each it'll work out -- except in California ;D
-
Function Block and RLL gets my vote
-
I am really surprised to see ladder logic is on the top of the list. I believe and stand-by the stage programming. Expand the I-box idea and AD really has something. My quess the reason ladder is on the top is that either people coming from the old school, or Allen-Bradley, or just are afraid to try it. Switching to Stage eliminated problems in my programs and got rid of the one shots. So much cleaner to trouble shoot with stage and follow. Hope more take the plunge and try stage programming.
-
I would like to see the IBox idea expanded...
In my humble opinion, it would be great to have user programmable IBoxes (like with structured text/basic), that we can cut and paste elsewhere in the program.
Stage is usually a better bet than ladder, but I have had one or two occasions where it was simpler just to whip up a quick ladder program, or to use a combo...
-
I also have to put my vote in for function block diagrams. I personally would rather use Structured Text for everything, but my colleagues would rather not even use controllers that don't use function blocks to program with. While it isn't superior to any method of programming it is less intimidating for people who have a background in pneumatic instrumentation and control but not in programming computers.
A hybrid type programming like is used by Rockwell would be the best so that everyone would be happy.
Thanks,
Mike
-
A hybrid type programming like is used by Rockwell would be the best so that everyone would be happy.
First, let me thank you for your input!
Yes, that is our goal. Right now we support 1 language (Ladder Logic). We definitely want to support N languages (mix and match). The question then is, how big is N, and which specific languages should we implement, hence the purpose of this poll ;D.
-
ST, RLL, and FBD
-
Being as technologically challenged as I am, I find many of the Intelligent Boxes a great help. I do wish that to make it easier for me to troubleshoot, that when I have the status function turned on, that single elements within the I-Box would also be highligted when active.
-
The type of programming language depends on the application.... For heat/cool control a function block is better. For standard applications, basic relay logic is good.. For applications that have sequence of events then sequencing is good... It just all depends on the specific application...
-
FBD & RLL I do a lot of programming with the other "A*" plcs (my clients choice - not mine!!) and have found that I use the FBD whenever there is a need for analog manipulation or numeric selection etc. It permits very complicated routines to be constructed very quickly with only a few blocks and makes troubleshooting and following operating logic easy and direct. Attempting to do the same with RLL - even with an expanded instruction set sometimes is close to impossible. On the flip side, doing boolean logic in FBD is - well - just plain painfull!! (anybody ever use opto22???) I wish DS had the FBD functionality - that would permit me to use AD a great deal of the time and cut down on someone elses market share...
-
I am really surprised to see ladder logic is on the top of the list. I believe and stand-by the stage programming. Expand the I-box idea and AD really has something. My quess the reason ladder is on the top is that either people coming from the old school, or Allen-Bradley, or just are afraid to try it. Switching to Stage eliminated problems in my programs and got rid of the one shots. So much cleaner to trouble shoot with stage and follow. Hope more take the plunge and try stage programming.
I've tried using the stage programming a couple of times but had less than good results - maybe I'll look for some better tutorial info and try again. Question that I have - typically what type of programming do you do - continuous process or batch? I believe that makes a difference as to which language works best.
-
I don't know what others use as a programming style, but for large projects I use outside resources (in my case Excel) to track the elements, nicknames and the whole memory map. Then I overlay the logic and import it to DirectSoft. I would hope that whatever you use will allow me to import and export code in a textual basis.
I troubleshoot using the ladder.
Thanks,
Dave
-
I only have experience with RLL and FBD, but if I could learn a text-based language that allows programming via the keyboard (primarily - rather than all the point-and-click associated with FBD) I would prefer that.
I find it cumbersome to use the mouse for data entry (point, click, drag, etc.) - which is what I like about DS5, lots of hotkeys & navigation via the keyboard.
RLL or FBD is almost necessary for monitor/troubleshoot operations IMO.
davebay- I can see using Excel for tracking memory designations, etc. But what do you mean when you say "overlay the logic" - don't you still need to do the RLL/stage/mnemonic programming once you have everything else laid out & organized?
-
scadapro, sorry I did not see your question earlier. You asked what do I use for programming. When it comes to AD, I use stage programming and depending on how intense it is, I go with a DL250 or DL260. I love the i-boxes. If the machine simply does sequential things to having to do multitasking I still use stage. It is wonderful how each operation can be in a stage and then use it how every and when ever I want. It eliminates all those one-shot and blocking this and blocking that. Examples of stages are Supervisory, Thermocouples, Faults, HMI messages, Conveyor Motor, Cooling Motor, etc. Makes it easier to find things. If I want to see why the Cooling motor is not going, I just go to the Cooling Motor stage. It does take some discipline and practice, just like anything else. A nice benefit is as the program gets large, the scan rate stays small due to the plc is only reading active stages.
-
I only have experience with RLL and FBD, but if I could learn a text-based language that allows programming via the keyboard (primarily - rather than all the point-and-click associated with FBD) I would prefer that.
I find it cumbersome to use the mouse for data entry (point, click, drag, etc.) - which is what I like about DS5, lots of hotkeys & navigation via the keyboard.
But that's a strawman. There's no reason FBD couldn't be entered from the keyboard. A text grammar and hot key system would have to be developed, but it's no less natural than ladder, which can be depicted either graphically or in mnemonics. Now as far as why one would want to use FBD in the first place..... :D
Actually, while I never did understand the appeal, there must be something to it because it sure has a lot of ardent defenders.
-
If you're a EE, FBD looks more like a circuit design
If you're an electrician, ladder looks more like mechanical relay diagrams
Also, if you have LOTs of elements being ANDed ORed ADDed (whatever) together, FBD is much more compact than ladder
-
Really? I can't imagine that. I'm picturing each FB about the size of a ladder contact, then you have to have space in between to route all the connections. It just doesn't seem possible. Do you have any screenshots that illustrate what you're saying?
Now I'll admit ladder isn't very efficient at ORing a whole bunch of single or simple conditions (long vertical column on the left that may even go off screen) so what I usually do is AND all the inverses, then put a NOT on the rail before the coil.
Now I'm an ME, so I spend most of my time calculating if the PLC base is strong enough.
-
The function is just a box, and the elements going into the box are just that elements, along with some lines.
With Ladder, you have to display the contact AND the element for EVERY element in the rung. Lots of overhead for the contact, vs. one & or >=1 box (that is OR)
+-----+
| |
| & |
| |
+-----+
+-----+
| |
| >=1 |
| |
+-----+
-
Still not quite getting it. Are you saying a single AND box, for example, will take more than two inputs? I thought in most implementations, you had to do n/2 boxes, then AND those results, then those results, etc.
-
Yes, that's why it's more compact, you can have 2..N inputs to a single & box. Same with "add", so you can add 20 numbers with a single + FBD box.
-
Some of you are over my head with this programming. I vote for the Stage, then ladder. One because I cut my teeth on the AB SLC100, did some real elimentry ladders and rewrites from some older TI units when they would crap out( years ago) .
I recently learned how to do the stage, I like it, I don't mind learning anything new.This function box, block, is that what is used for robotics or is it the flow charts? Either way I wouldn't mind learning it.
I would like to learn what is used for CNC machines, lates, mills, ect. I plan to build a table top CNC machine for myself, been researching steppers, servos, and how to control them with the printer port from my PC.
I would like to see ADC to come up with a DRUM that you can change timer values on the fly via HMI, that would useful to me, I could use that today at work on about 25 machines.....
-
I think stage is the best for most uses. Standard RLL works for simple projects (light on/light off). But having an electronics background, I REALLY enjoy Function Block Programming. I used it on a few seimens PLC projects and it was like drawing a schematic and putting it in a box and voila, project done. ;D
-
While I love Function Block Diagram in modicon Concept, there is one drawback: What about the poor bastich electrician trying to figure it out at zero-dark-thirty in the morning who has never seen it befoe and doesn't know what that little circle on the input means? Don't scoff. I've been there and been called in to explain to the _Electrical Superintendant_ what was going on because _he_ had not bothered to learn anything but RLL. For simplicity and uninterupted nights, I'll take RLL.
-
While I love Function Block Diagram in modicon Concept, there is one drawback: What about the poor bastich electrician trying to figure it out at zero-dark-thirty in the morning who has never seen it befoe and doesn't know what that little circle on the input means? Don't scoff. I've been there and been called in to explain to the _Electrical Superintendant_ what was going on because _he_ had not bothered to learn anything but RLL. For simplicity and uninterupted nights, I'll take RLL.
We will NEVER drop RLL. However, we would LOVE to add other languages, but "all of them" is not the right answer. ;D
-
I also vote for Function Block Programming! Another feature, while related to programming but not, is how variables/tags are declared and used. The ability to define user data structures is very powerful. Another item is the ability to define a program hierarchy. A main program has several subroutines in it, and each subroutine has subroutine within it etc. The ability to see this graphically is very powerful especially for large programs. Stage programming does some of this, however many programs are not suited for stage programming.
-
Function Block is nice and usefull. However when doing a lot of math or more complex equations structured text seems to work well as long as no data conversions are required while doing the structured text. How about allowing the user to create custom iboxes with the programming language of choice. And like some of the other users I'c like to see more structure options, Main program with other subtitled programs. They wouldn't even have to be subroutines just a way to divide the program up into subsections for ease of troubleshooting.
-
Definitely FBD!
Please add this feature to the DirectSoft program. FBD is among my top consideration, when selecting a PLC.
Is there any chance FBD will be included in the next version of DirectSoft or CLICK in the near future?
Jeff in Florida
-
The results of this poll are meaningless without FBD as a choice.
How about a redo?
-
The results of this poll are meaningless without FBD as a choice. How about a redo?
I definitely see your point, but the sample survey data is still somewhat valid due to having the "other" category. If we assume all (currently) 14 "other" votes are for FBD (out of 140 current participants), it shows us the general popularity, which is all you can hope for in a random sample poll anyway.
-
Meaningless? Nah...just incomplete.
Probably would be good to add it, though, if we can do so without losing our statistics. I think there will be a few folks that vote for it, but I wouldn't anticipate it being in the top 3. But hey...I've been wrong before. :o
-
Probably would be good to add it, though, if we can do so without losing our statistics
All you can do is start over with a new poll and delete this one ::)
-
Then again, some of those options aren't exactly going gang-busters. Might make sense to refactor and relaunch, making note of what we learned. In v2, we probably should have all of the 61131 languages represented. Our FBD fans will be thrilled. ;)
-
I eliminated LUA (it had 0 votes anyway), and replaced it with FBD! Also, we got an update to this forum software, and this new version allows you to modify a poll (i.e. add new categories).
-
Actually, I think you removed Perl. Lua is still there...and still as useless as ever.
-
LOL! Freudian slip? So Perl is not as popular as Lua (0 to 1). Oh well ;D
-
Thanks Franji1 and I am the first FBD vote! Wahoo!!!
-
uman i would have been the first if it exsisted when I voted. ;D I like the FB too. We currently are using a servo system that allows us to use SFC, Ladder, or FBD. But then again it is a very expensive system using a INTEL processor. I am amazed the ladder is winning the votes. I just ran into several guys who absolutely refused to try the stage programming even after they looked at my program and saw how well it was layed out and easy to find things. These same guys tried it for a couple of minutes then gave up. I think they call this closed mind. Anyhow, just wish others would give it a try. Where is the spell checker, I need one badly.
-
I wish Koyo had program blocks. I have to use stage programming just to organize and find stuff. I programed Siemens for years and realy miss being able to organize my programs by program blocks.
-
Program blocks? Your patience will be rewarded. New controller currently under development by Host does that and more!
-
I usually use a combination of relay ladder and a BASIC coprocessor card.
-
I also would like the IEC languages particularly FBD for portability
James
-
"Which combination of programming languages would you prefer to use in a future PLC? "
Prefer? Ruby!
-
Well, I guess we already got the rails. :D
Seriously? Dude, we just got Perl OFF the list.
-
Perl? Here's an irony...Perl is the core of our automated testing for our new PLC. We use Perl to generate all of the test scripts, and our test guy seems pretty fond of it. Of course, he's a Linux bigot too, but he works hard and does a good job, so we overlook these things. ;)
Smile Doug, if you're lurking. ;D
-
Malbolge: as clear as Perl with a more entertaining and less girly name:
('&%:9]!~}|z2Vxwv-,POqponl$Hjig%eB@@>}=M:9wv6WsU2T|nm-,jcL(I&%$#"`CB]V?Tx<uVtT`
Rpo3NlF.Jh++FdbCBA@?]!~|4XzyTT43Qsqq(Lnmkj"Fhg${z@>
("Hello World" in Malbolge)
-
APL?
-
Are you suggesting putting APL in or asking if that's what that sample was? If the latter, I just randomly typed symbols from Shift+Nums, so it was actually Perl.
-
If the latter, I just randomly typed symbols from Shift+Nums, so it was actually Perl.
aka, APL ;D. Actually, A Programming Language had its own keyboard with symbols you don't see on a QWERTY keyboard or ASCII table. Some implmentations had ASCII translations, but it was its own beast (see attached JPG)
-
Pleeeeeeese give us another option other than ladder logic! It's driving me insane! ??? ??? Some sort of traditional language like c/basic or similar would be great. :)
-
Pleeeeeeese give us another option other than ladder logic! It's driving me insane! ??? ??? Some sort of traditional language like c/basic or similar would be great. :)
Have you seen the WinPLC? It's a 205 CPU that has Windows CE 2.12? on it.
-
I don't know how many of you have had access to Allen Bradley RSLogix but after being forced into learning it, I have found many features that make life really easy. It would be nice to see something like this or the P3000 PLC software. Hopefully we will see something new come out for Directsoft in the near future, it is ok for programming but sometimes it seems a little backwards now.
Mike
-
Which type of RSLogix (or which PLC) are you referring to? Which features of that programming package do you find especially useful when compared to Directsoft?
-
Hopefully we will see something new come out for Directsoft in the near future, it is ok for programming but sometimes it seems a little backwards now.
Major development in the closing stages. New PLC, new control engine, new DSP. We are pumped about it, and we think our users will like it. That said, like Bernie, I would love to know what you like the best in the new RSLogix...
-
Data view. ;D
-
Structured Text. I love being able to write a supervisory control application directly on the plc that interacts with the real time control elements -- SFC, Function Blocks and Ladder.
-
I like the RLL implemented in Directlogic processors so keep that. I absolutely love the stage programming capability DL has so keep that where it is at. The only 2 languages I would like to see added to a PLC is basically a DL205 type system capable of Function Block with multiple instance capability. Being able to build libraries of technical solutions in a function block that has parameters passed by value rather than reference is like being able to write whatever instructions suits a person best. It's hard to beat. Having SCL or some structured basic style language like QuickBasic or C would be nice but I would not use it most of the time.
I like DS stage as much as SFC and don't see any differences apart from presentation. Without stage or reentrant FB with instance, it's hard to build a plc system that is threading 2 robots in the same space over a moving dial with various part programs issuable.
-
I like the RLL implemented in Directlogic processors so keep that. I absolutely love the stage programming capability DL has so keep that where it is at. The only 2 languages I would like to see added to a PLC is basically a DL205 type system capable of Function Block with multiple instance capability. Being able to build libraries of technical solutions in a function block that has parameters passed by value rather than reference is like being able to write whatever instructions suits a person best. It's hard to beat. Having SCL or some structured basic style language like QuickBasic or C would be nice but I would not use it most of the time.
I like DS stage as much as SFC and don't see any differences apart from presentation. Without stage or reentrant FB with instance, it's hard to build a plc system that is threading 2 robots in the same space over a moving dial with various part programs issuable.
I think you're gonna like our new CPU based on the MX Technology Preview. It's still in the works, but we're in the final stretch. It takes Stage to the next level, although it does not yet have a true stage EDITOR, but plans are for it in a future version of this PLC.
-
I have been playing with it the last couple of hours and I think it is going to be great. I noticed in the help file under tasks that functions with parameters passed by value OR reference is promised. Now THAT will really excite me.
-
I have been playing with it the last couple of hours and I think it is going to be great. I noticed in the help file under tasks that functions with parameters passed by value OR reference is promised. Now THAT will really excite me.
That won't be in the first version, but definitely planned for Rel 2. Rel 1 supports modular programming with "program" code-blocks and "task" code-blocks.
The PLC already supports parameter values and references passed on the stack, along with local variables, but to get the "user experience" top-notch, we knew it was gonna take some real work. For example, we want you to be able to quantify a numeric parameter type for a function in ANY of the following ways
BIT_OR_NUMERIC (any bit or any sized numeric including reals)
NUMERIC (real or integer)
REAL
INTEGER (any sized integer)
BIT_OR_INTEGER (any bit or integer)
SIGNED DWORD INTEGER (strong type, D memory in MX)
SIGNED WORD INTEGER (strong type, WX/WY analog memory in MX)
SIGNED BYTE INTEGER (strong type, no default data-blocks of this type, but you can create your own)
UNSIGNED WORD INTEGER (strong type, V memory in MX)
UNSIGNED BYTE INTEGER (strong type, no default data-blocks of this type, but you can create your own)
So if you had a parameter that was BIT_OR_NUMERIC, that could take X7, V22, R44, 3.14, 42, etc. If you had something that was INTEGER, it would take V22 or 42, but not X7 nor R44 nor 3.14. If the parm specified SIGNED WORD INTEGER it would take WX4 (16 bit signed analog input, which happens to be an signed 16 bit word integer) or 42 or -32768, but not 65535.
These details are all drawing board stuff planned for Rel 2, but you get the idea.
-
So if you had a parameter that was BIT_OR_NUMERIC, that could take X7, V22, R44, 3.14, 42, etc. If you had something that was INTEGER, it would take V22 or 42, but not X7 nor R44 nor 3.14. If the parm specified SIGNED WORD INTEGER it would take WX4 (16 bit signed analog input, which happens to be an signed 16 bit word integer) or 42 or -32768, but not 65535.
How does that work when using a module that actually has 16 bits of measurement resolution? Will we need to do a math operation / cast to get it into U16?
Or are all of the 16-bit modules already bipolar-only?
-
WX4:U
-
WX4:U
Thanks, BobO!
-
Thanks, BobO!
And in the 'new world', we let you document WX4:U...so if you were to actually use nicknames (I know you don't like them) you would only enter it once and never worry about it again...
-
Or are all of the 16-bit modules already bipolar-only?
Not sure...but I'm thinking 16 bit unsigned exists. The answer is the same though...WX4:U.
-
205 has 16 bit unipolar modules.
-
No Question -- Relay Ladder Logic Programming
-
Jam,
You are a bit late to this party. Take a look at Do-More BRX
-
Jam,
You are a bit late to this party. Take a look at Do-More BRX
Needed to remove that anyway. It wasn't what it seemed.