Host Engineering Forum
General Category => General Discussion => Topic started by: BobO on April 25, 2007, 11:19:50 AM
-
Ok...realizing that I might find myself frightened by the proposals..;)..I'd love to hear your thoughts.
Simple question: If wishes were free, what changes would you make to the DirectLogic PLCs?
We're leaving this wide open, so don't be timid! Post!!
-
features i would put into the PLC are:
-possibility to send larger emails.
-standard ethernetport inside ( i know it will cost more, but almost every PLC i order now i have to order also a seperate ecom100 what will cost me 1 expansion slot(and money ;) )
-support for usb so i could connect for example memorystick or a barcodescanner to it, but it should also usefull to program the PLC.
- Optional cards so the plc could also be a master for: CANbus, PROFIbus, DEVICEnet.
that's it for now, if i have more ideas you will hear it
-
For DirectLogic:
The ability to subdivide a project into multiple files or ladders, somewhat similar to RSlogix. Doesn't have to be the same, just a better way to "compartmentalize" a program.
For PLC's:
A co-processor card with a i386 type processor, USB and Ethernet so I could run Linux.
C-more:
A variant with linux.
LookoutDirect:
A version that runs on Linux.
Yes I am somewhat of a Linux Fan.
-
I agree with MLK on the ethernet and usb. The ethernet card for a DL205 is 299 so a little more cost would be okay.
AD has the terminal blocks you can use as Devicenet etc. I believe they are call T1k. Why not have a CPU and use it. Some manufactures are coming out with I/O with a CPU onboard. Nice idea, it eliminates I/O blocks having to be added to a PLC inside the cabinet. I generally wire from a PLC I/O to a bank of terminal blocks for easier wiring. The T1k series with a CPU would be nice. Less space.
HMI with the PLC built in are appearing on the market also.
Some of the features of Allen Bradley software such as being able to cut and paste individual I/O in ladder is neat. In AD you have to copy the whole rung versus AB you can paste just the one item
Just giving what I see on the market, I really like using AD and would not want to see AD fall behind on latest trends.
-
Hi, just gona agree with some of the others...but i just noticed you fixed some stuf (ver 5.1)with window docking & stuf, good job.
Agree with PLCGuy
Some of the features of Allen Bradley software such as being able to cut and paste, highlight, drag then drop (or kind of copy) individual segments of ladder is neat. In AD you have to copy the whole rung versus AB you can paste just the one item or grouped items.
Ive been using others software so long i just started using AD 2 years ago. Im used to writting ladder knowing im going to cut just sections of it and paste or highlight(copy)/drag/drop-paste. It would also be nice to be able to write partial rungs without having to finish the rung but have the program save like a draft.
Quote: Acadien
The ability to subdivide a project into multiple files or ladders.
Like Acadien, it would be nice to have a "folder" or "split view" that could be opened and closed in the ladder. I also would like to see better handling of mutiple windows. I use 3 21" monitors and it would be nice to have each ladder window have its dedicated xref window/data window.
As a direct answer to the question, changes to the plc, hum, maybe this is still sofware related... how about puting the pid stuf into the ladder instead of somewhere outside. its kind of frustrating having to go out of the main ladder to figure out whats going on in the PID. Havin the pid in the ladder would make it easier to troubleshoot, program i think. If it was a folder in the ladder like stated up above?
-
My $.02,
I agree with the above posts, especially about being to divide the program into files or such. But the improvements that I would like to see are:
+ Being able to use the comparison instructions on something other than BCD, like real or binary.
+ Doing a search on a specific memory address that is used in a formula within an IBOX does not show up in the search results, nor does it in the XRef view that it is actually being used in a particular ladder rung. The only way that I can find it is to manually scroll down through the program until I come upon it.
+ A inconvenience that I run into frequently is - for example, I have quite a few analog values that are in bin format, but in order to do some manipulating (floating point math) on these values, I must convert all of these addresses into Real. Then when I have to use the comparison instruction, I have to convert yet another time to BCD. What I end up with is lots of BIN, REAL, BCD values of all of the analog memory addresses. I need an easier way to do all of this math without all of the duplicate versions of memory addresses.
+ A ramping IBOX that is NOT filtered. I would like to specify a starting point and an ending point with something like a rate variable that I can utilize in a linear fashion, instead of the FILTER or FILTERB IBOX which is not very linear.
+ A more versatile analog scale IBOX. One that you can specify more things then just hi and low engineering values. For example, be able to scale counts (2000 to 1000) to (1500 to 4000). Inverted scaling. I had to scale an analog input value from 2.1 volts (860 counts) to 7.8 volts (3194 counts) scaled to output 0 to 10v (0-4095). It was fairly easy to do but it could have been easier with a more versatile IBOX. And more than just 12 bit resolution.
+ PID setup tab - Configure supports 12, 15, and 16 bit. The T1F-16AD-2 analog input terminator field I/O has a 14 bit (13 bit with sign) resolution.
+ A ramp soak IBOX or something of that nature that shows the time elapsed and remaining in a particular ramp/soak segment. And a CANCEL or STOP for the ramp soak, not just the start/hold/resume/jog.
Justa few minor observations, that is all that I can think of on the spur of the moment.
Robert
-
Ok guys...thanks for the feedback so far! Keep 'em coming!
Without going into detail, I will say that a number of these features are going to show up in products in the future. I won't say which features, and I won't say when, but cool new stuff will be coming out... ;)
-
just some other thoughts:
-full duplex serial communication on the serial ports so you can read and write at the same time:)
-MRX and WRX boxes for H0-ECOM100 .
-more memory and some kind of recipe function.
-
A few things that come to mind:
----------
DirectSoft: Complex AND above a JOIN
I would love to see all the RSLogix type features mentioned above implemented into DirectSoft. Dividing my programs into individual ladders would be great, but I love Logix's data view. It's nice to hover over individual bits and see the description. Changing values is also a breeze. I guess I would also like the ability to FORCE inputs and outputs, but it's not that important to me.
----------
ECOM Modules: Ability to authenticate with an SMTP server
Chris
-
The more numbering systems you have available, the more confusing things can get. Each numbering system has some advantages, so it becomes difficult to get rid of any of them - with the one exception of BCD. BCD is a system made up of all the disadvantages of the other numbering systems. It can't show polarity. It can't keep track of decimal points. It's hardly efficient to use up 16 bits and only get 4 unsigned digits.
Hex does have an advantage in getting larger numbers in smaller spaces, but Hex and BCD are both products of the bad old days when hardware was slow and programmers were cheaper than microprocessors. It's time to get BCD and Hex out of the software we are creating now. While we're at it, in AD programming, Octal isn't as annoying as BCD since it doesn't hide in the data, but why do I have to do entries in base 8, when everything I'm working with is a computer that can make the conversions way faster than I can?
Goodby to BCD. Goodby to Hex. Goodby to Octal. Humans work in Decimal numbers and computers are just going to have to learn to cope with it.
-
Sweet! Thanks guys! Bring them on...
Regarding numerical radii: Despite there being 5 displayed formats, there are really only 3 encoding schemes: BCD, real, and integer. Meaning...octal, decimal, and hexadecimal are all encoded identically...despite being displayed as radix 8, 10, and 16. At times each has its purpose, but doesn't effect the way the hardware sees the number. The values 012, 10, and 0xA are all the same in hardware...the 4 bit binary value 1010.
While octal numbering is frowned on by many folks, many consider it easier to use when the underlying I/O is grouped by 8s. Is it easier to have X0-7, X10-17, and X20-27...or...X0-7, X8-15, X16-23? It's a matter of preference and there are folks on both sides of that argument. Octal does cause confusion at times though.
Now hex is another issue. As a programmer, having a number system that makes it easy to directly see specific bit or byte values is invaluable. In the code that I write, I routinely use both decimal and hex...specifically because I need to visualize bits. A value of 0x12345678 allows me to see the bit values in each nibble of a 32 bit integer. At times, that is hugely beneficial...say when trying to isolate individual bytes due to each byte having its own meaning. That same number expressed as decimal is 305419896, and clearly each byte's effect on the total number is completely obscured.
BCD on the other hand, is a holdover from a bygone era and has no practical purpose in a modern controller.
I think the real answer is a more flexible system that allows you to choose base 8 or 10 for I/O numbering...since both have value...and constants that are user selectable. In "C", we can specify base 8, 10, and 16, as well as floating point, simply by the way we enter the value. An octal value has a leading 0...04000, a decimal value is just the number...2048, a hex value has a leading 0x...0x800, and a floating point value has a decimal point....2048.0. All 4 of those values are 2048. The octal, decimal, and hex versions encode to an integer, and the floating point is a 32 bit "float" in "C" parlance.
With a system like that, you can basically do what you want. No more K1, or R1.0....just 4095 or 0xFFF or whatever...your choice. Any problems with that approach?
You never know....stuff like this may be coming to a DirectLogic PLC sooner than you think. ;) We are certainly listening....
-
That's exciting to hear, Bob!!! ;D
I was originally going to post one other idea I had earlier, but can't seem to recall what it was. That's okay; another one comes to mind.
One of my co-workers, though, has been working with controllers from Z-World, and their SBC's allow you to upload your own custom HTML files. I don't know if it would be possible or not in future versions of the ECOMs, but it would be great to have that capability! :)
Hey! My memory came back!!! :D How about an iBox for Report-By-Exception?
Chris
-
Features within the PLCs themselves
1. Ability to have timers and counters work with binary instead of BCD (systemwide selection)
2. AND above a Join, probably involving a 'logical push' and 'logical pop' instruction
3. Inline Double word and REAL comparisons
4. User created IBoxes - probably defined in the Interrupt/Subroutine area, identified by a number
Features within Directsoft
1. Ability to assign a nickname to a subroutine and call it by that nickname
2. The same for Data Lable areas
3. Use of the LDA command with a nickname
(Are you seeing a trend here?)
4. Assign memory space to a Data Lable by an amount of space without assigning a value to each space. Something like a 'Reserve Memory X' command in addition to the ACON and NCON commands. Directsoft may just generate a bunch of NCON's with 0 as the argument. That would be ok.
-
b_carlton,
Welcome to the Host Engineering forum! Nice mug! BTW, I don't look like Jack Lambert.
ALL your ideas are excellent, some of which we already knew about from the ADC forum. We are hot-n-heavy in the middle of development, and this is the kind of stuff we are looking for!
-
I'm preparing to be at home for 2 weeks, and a couple ideas came to mind. I was setting up the firewall at work to allow for connectivity to multiple controllers at work.
1. Export/Import Links
2. Allow for entering a domain name or IP address.
Here's one more that isn't important, but would be COOL. DirectSoft scans the network for ECOM's when setting up an ethernet link. How about the ability to enter specific search parameters, such an IP address (or domain name) and port numbers to scan. DirectSoft could then find all ECOM's that are accessible from outside a firewall.
Like I said, it isn't important, but it sure would make things easier. :)
-
Just found this forum, sorry if I'm late :o
I agree with most of what's here so I don't have much to add, but...
I've always wanted to be able to expand/collapse stages in the ladder view; seems like that would be one way to have the multiple ladder concept easily within the current PLC hardware design.
-
I would like to see an additional option on the XRef View. I would like to be able to set it so it would display anything I have supplied a nickname for, even if it has not yet been used for anything. Also, if I'm using XRef in its usage mode, I would like to see an item's location as being used in every case where I have given it a nickname.
I would also like a search function so if I thought that what I was looking for was around V2310, I could jump to it and see what's in the neighborhood. Browz will let me see V2310, but it doesn't show what's around it, and I have to exit from it and close its window before I can do anything else.
I would also like the usage mode to pick up on ranges that have been defined. If I set aside V2000 - V2025 for input from a CTRIO, the usage table says they're free to use however I want. I need to be able to provide nicknames for the individual registers, but they should be marked to let me know they're in a range that's not totally free. Maybe color could be used. If a range is defined, that range will show up in yellow on the usage chart.
-
Documentation - Nicknames. Being able to assign a nickname to a block of locations with a specified method for incrementing a part of the nickname.
For example - I want to reserve V2000 through V2007 for "Reading". I select the group of locations in the documentation wihdow specify then nickname as "Reading_[0-7]". It then automatically assigns V2000 = "Reading_0", V2001 = "Reading_1", V2002 = "Reading_2" etc.
Though I guess we can always export, modify and reimport the nicknames.
-
Though I guess we can always export, modify and reimport the nicknames.
One of the options in the Import Element Documentation dialog is to merge with the existing database, so you only need to create the Nicknames you need, e.g. V2000 - V2007.
There are actually 2 Merge options based on if any collisions occur (e.g. a nickname already exists for V2003 AND the input file has a nickname for V2003). One gives priority to the existing Project's nickname (.PRJ priority), the other gives priority to the input text file (.CSV priority).
-
One new feature that I would like to see in NetEdit would be the ability to change the Ethernet Timeout setting the way that you can in Directsoft under the advanced settings for the link setup. NetEdit works OK for most of the PLC's we have connected, but we have some that it cannot see because the timeout period is too short. I assume that if you made the timeout period too long that it could take a long time to finish the network scan, but it would be useful to have this ability. If you could change the program so that the timeout period was adjustable, and the program was set up so it did not do a network scan when it was first launched, then you could run the program, change the timeout to whatever you needed, and then manually press the network scan button. Alternately, the network scan could be set up with a check box to pick whether you wanted to run it automatically when the program launched.
-
Here is a feature that I would like to see in Directsoft. A lot of the outputs that I program are to V-memory locations, and it is inconvenient to have to bring up the instruction box before typing OUT to get an OUT output box for a V-memory location. If you just type OUT over a NOP instruction, it always programs a binary output - single bit coil. I would like to see an instruction added like OUTV that would enter the V-memory output box over the NOP instruction just by typing it.
-
Here is a feature that I would like to see in Directsoft. A lot of the outputs that I program are to V-memory locations, and it is inconvenient to have to bring up the instruction box before typing OUT to get an OUT output box for a V-memory location. If you just type OUT over a NOP instruction, it always programs a binary output - single bit coil. I would like to see an instruction added like OUTV that would enter the V-memory output box over the NOP instruction just by typing it.
This was one of the reasons why we added Tip-of-the-Day in Rel 5 (lots of hidden stuff people don't know about). Hit the slash key with the OUT coil. It changes it to the OUT box, then slash again takes you back to the OUT coil. So just type
O U T <enter> /
and you're there!
This is tip #23 To place a new OUT Box quickly, place your cursor over the NOP or an empty location, type "OUT" (without the quotes), hit Enter. This will give you an Out Coil. Then hit the forward slash key "/" to "toggle" between the OUT Coil and an OUT Box.
They're actually NOT numbered, but it makes it sound more cool 8)
There are actually a BUNCH of goodies in the Tip O' The Day. If you don't want to read them in the DirectSOFT TOD dialog, someone actually posted them on the web: http://www.plcdev.com/directsoft_5_tips (http://www.plcdev.com/directsoft_5_tips). There's actually a few more with Rel 5.1 and Rel 5.2 that are not listed there (Rel 5.2 is a free maintenance upgrade to all Rel 5 users). Here's the link for that http://www.hosteng.com/TheDownloadPage.htm (http://www.hosteng.com/TheDownloadPage.htm).
Like Math IBoxes display their results when status is turned ON. DirectSOFT On The Web. Support for serial ports COM1 thru COM199 (not just COM1 thru COM8). Oh, and a few bug fixes ;D
-
there's another way to get there : hit f7 then type o u t <cr>. f7 brings up the box browser which defaults to creating an out box.
f7
out
<cr>
boom, you're ready to enter the memory location. it's no fewer keystrokes than using the "/", it's just what i got used to doing.
-
Suggestion from a Forum newbie - Directsoft - Unless this is a current feature that I don't know how to enable, I would highly recommend adding the cross-reference for addresses used within the calculations of an Math I-Box.
-
I would highly recommend adding the cross-reference for addresses used within the calculations of an Math I-Box.
I wish it currently worked as you desired, but it doesn't :-[ Excellent recommendation, one that we're addressing for Rel 6.
-
I just wanted to add my two cents. I think that having a way to separate the logic in to sections or subroutines would be a very nice feature. Having everything in one extremely long ladder diagram is cumbersome to look at. I have one program that has over 1000 rungs in it and sometimes its hard to find a certain routine because it is in the middle someplace.
A DeviceNET scanner would be really nice. It would expand the compatibility to many more suppliers.
Binary counters are another good suggestion that I will second. In RSLogix5000 (its not in 5 or 500) there is only 1 time base (ms) and a 32bit binary accumulator good for 4294967295ms (49.7 days). I have had to cascade timers to get the value I needed. this is not very efficient.
Keep up the good work.
-
I think that having a way to separate the logic in to sections or subroutines would be a very nice feature
Several AD Plc's have subroutines and you should look at the Stage Programming feature.
Binary counters are another good suggestion that I will second. In RSLogix5000 (its not in 5 or 500) there is only 1 time base (ms) and a 32bit binary accumulator good for 4294967295ms (49.7 days). I have had to cascade timers to get the value I needed. this is not very efficient.
Are you refering to Timers or Counters? If you are looking for large Minute, hour or day counters. The UD Counters are double word capable to 8 digits and you can trigger those with the system timing bits.
The RSLOGIX5000 software is quite powerful, but you are paying for it in multiple 1000's of dollars for a system. I think the AD line can be equally as powerful in certain circumstances if you become familiar enough with its capabilities.
-
This is a small thing, but in DSLaunch under the projects, I would like the files to show up alphabetically rather than the order they are created.
-
we're going to completely revamp dslaunch for directsoft v6.
one of the many changes will be to let you sort the list of projects alphabetically, by date, by plc type, by connection type and by any other criterion we can come up with (that makes sense).
-
While this can be done in DS500.INI I would like to be able to select a group of the projects in the launch window to remove them (from the window only - don't even present an option to remove them from the disk!).
-
I would like to see a "warning" for double Vmem counters and timers that we about to "step on " an adjacent timer or counter Vmem address. Perhaps with a "don't warn me again" check box for the programmers that don't want the warning and like to live on the wild side.
So if you were editing a program and you decided to change a TMR to a TMRA as soon as you completed the timer box (and an adjacent Vmem was already assigned) then the warning would appear. Or if you decided to add a TMR and the address was already assigned to a TMRA then the warning would appear.
-
I have to agree on warning about double word outputs of I-boxes. I had an issue with this when upgrading to one of the new 16-bit analog cards. Can you make 16bit bin single word and let 16bit BCD go double word. I rarely use BCD, someone who uses both may feel differently on this.
Another thing is the constants, K-values, in the math I-boxes. Can we get H for hex or D for decimal. I frequently have an analog conditional argument in K(hex) leading to a math i-box where everything has to be K(decimal).
-
Another thing is the constants, K-values, in the math I-boxes. Can we get H for hex or D for decimal. I frequently have an analog conditional argument in K(hex) leading to a math i-box where everything has to be K(decimal).
We're currently experimenting with specifying constants like you do in C:
10
0xA
012
These all represent the same value as "one more than 9"
We prefer this over creating "type" constants (e.g. K, H, O, D, R, B).
The hard part is the "upload" issue. The PLC instructions does not store the type, so there is no way to "reverse compile" the program and get what you started with.
What we are looking to do, is allow you to enter
V1000 + 0x0A
V1000 + 10
V1000 + 012
and they would all add 10 to V1000 (assuming, of course, we're dealing with decimal).
Basically, we don't know what you are doing (e.g. pointer arithmetic? you may want to use octal constants???), so what if we let you use WHAT YOU WANT! (what a concept!)
-
I agree with the earlier post on the need for 'master' Profibus capability. Also, need more motion control capability. We tried CITRO with stepper motors but were not satisfied. With AD now selling servos, it seems a logical next step to have advanced motion control and communication.
-
It Would be super helpful to me if DS's PID Trend view could record the trends for multiple loops simultaneously. I have a hard time trying to tune some of my cascading loops whenever the process is slow acting, and one loops tuning affects the other. I only need to view one loop at a time, but if I jump from loop to loop, my trending graph starts all over again. Thanks for a great program and a great forum!!!
Jason
-
It Would be super helpful to me if DS's PID Trend view could record the trends for multiple loops simultaneously. I have a hard time trying to tune some of my cascading loops whenever the process is slow acting, and one loops tuning affects the other. I only need to view one loop at a time, but if I jump from loop to loop, my trending graph starts all over again. Thanks for a great program and a great forum!!!
Jason
I'll second that!
-
Also, need more motion control capability. We tried CITRO with stepper motors but were not satisfied. With AD now selling servos, it seems a logical next step to have advanced motion control and communication.
We have kicked around motion on several occasions, but find that we really don't know much about the subject. What exactly should we be doing that we aren't? Our challenge is to present a simple but powerful solution, that answers more questions than it creates. It is easy to create features, but in AutomationDirect's market space, it is important that the features be simple to use and very supportable via the telephone. Put another way...if you could choose 5 well-bounded motion behaviors...what would they be? I say behaviors as opposed to features, because I am more interested in what you are trying to do than I am in the features that most folks use to do them.
-
New feature?
Actually, my corporate network police almost had a cow when they discovered that the new Ecom100's have built-in web hosting to set parameters that is not password protected and can not be turned off. And then they went on to point out how easy it would be for someone to screw up a working PLC totally just by running across this feature and typing random crap into every possible field.
I know PLC's should not be on a "real" network . . . but I bet than I'm not the only person who still does it that way.
-
So what yer sayin' is that it is a bad idea to let folks screw stuff up? ;)
That's the irony though...some folks like the power and get mad when you take it away, and other's think it's horrible and insist that you do. You may have seen some on my comments elsewhere on the forum that talk about that very issue: where do we draw the line in giving folks a length of rope whereby they can hang themselves? I tend toward not doing so. Others disagree. We still get along. :o
This one seems like a clear problem though. I think we need to provide a mechanism for turning off the web server's ability to change stuff. Would someone from tech please see that such a thing happens? Soon.
PS. Just once would I like to be in the room when an IT guy actually gave bovine birth!! ;D
-
...I think we need to provide a mechanism for turning off the web server's ability to change stuff. Would someone from tech please see that such a thing happens? Soon...
I have entered a case in our database.
-
I like long rope . . . yeah, if your not careful, you can hang yourself, but when "other people" make assumptions about how you may want to use a certain type of device, you can almost bet that the decision that will be made will result in problems for someone somewhere along the line.
Case in Point. Graphing widgets in <someone else's product . . . which begins with C and ends with More>. Why are limits defined only during screen design time? I really need an auto-scaling plot. I swear sometimes that if I could only have gotten one of the old ez-touch panels but with ethernet, my life would be perfect. <Grin> That was a nice panel . . .
-
Not Ez-touch . . . whatever used the old Screen Creator software . . . the ones you could twiddle new features with in a version of basic.
-
I hear you, Pippin, however, the C-more nor the EZ-Touch panels and their software are/were our products. We did create the EZ-Ethernet and EZ-EtherPLUS cards that plugged into the EZ-Touch panels and wrote the section in EZ Touch Software that allowed you to configure them.
So your thoughts might be better served by posting on AutomationDirect's Forum. ;D
-
Trending of anything. I would love to be able to trend registers, IO, or anything for machine and/or ladder troubleshooting. Ibox's are the best thing ever created, so more improvements on those, like an ibox that allows you to right small basic or C programs. The ability to store an entire project on a plc with documentation. And for the radical, added support to program plc's using flow chart decision blocks (not stage, although I do love stage), or text, instead of ladder logic. For the super radical, the ability to program inverters and servo drives using directsoft, especially Iboxes custom formulas (for taperd tension winders or diameter calc)! OK, maybe I went a little to far, I will forward this to the north pole and see if Santa's Elves could help :)
P.S. I love the idea of on board usb and/or ethernet, especially since serial seems to be disapearing.
-
We're definitely addressing much of what jbrazington listed, although not everything will be in Rel 6 (but we're definitely looking at it for inclusion in a future version!).
Keep the wishes coming, especially with a little detail as jbrazington has done!
-
I would definitely like the PID trends to continue updating when they're not being viewed, as listed above. Being able to place multiple loops on a single trend screen would be helpful too.
An alerting mechanism regarding double word-using functions, such as TMRA's -- perhaps as an option to auto-populate the "Wiring" field with "DW-2", use the TMRA address concatenated with "DW2" as the nickname, or something. Currently just using the XREF to keep track of these things.
-
It would be REALLY nice if DS had optional rev tracking so that the development history could be accessed from within DS.
It would be nice if DS projects could be saved as a single file.
-
It would be REALLY nice if DS had optional rev tracking so that the development history could be accessed from within DS.
We implemented the project's Properties page that implements a way to enter VERY SIMPLE project maintenance information. See File->Properties. One of the predefined fiels is Version.
If you want to add any fields to this dialog, edit the DS500.INI file under [ProjectInfoUser] group and add or edit any fields that you want to show up in that dialog. This information will be printed with the Title page.
If you are looking for a true source control utility, we recommend using a 3rd party package, like Microsoft's Visual Source Safe, which is what we use for all of our source code.
-
How about adding the ability to programmatically change the IP number of the SMTP server on the ECOM 100!!!!!!!!!!!!!
-
How about adding the ability to programmatically change the IP number of the SMTP server on the ECOM 100!!!!!!!!!!!!!
It's already in Rel 5. It's the ECEMSUP (ECOM100 EMail Setup) IBox. You can configure 1 or all of the SMTP paramters from ladder logic:
1. SMTP Server IP Address
2. Sender Name
3. Sender EMail Address
4. TCP/IP Port Number (default is 25)
5. Timeout in seconds
6. Predefined cc: list
There's check boxes next to the fields you wish to edit:
-
MRX and MWX: It would be nice if the "slave address" & "number of element" fields could be held in an assigned "V" value. The older RX & WX functions allow this numeric value to be stored in a "V" memory location. This allows one to create one read or write function for common devices, simply change the data pointer and header address (nice compact code). The newer MRX & MWX has one feature which I could realy make use of, that being the exception response buffer. So giving the MRX & MWX just a bit more...(don't lock it down so tight) along with the much needed communication response information you've got it.
Speaking of communciation; why aren't the comm registers available to view for port 1 & 2?
-
MRX and MWX: It would be nice if the "slave address" & "number of element" fields could be held in an assigned "V" value. The older RX & WX functions allow this numeric value to be stored in a "V" memory location. This allows one to create one read or write function for common devices, simply change the data pointer and header address (nice compact code). The newer MRX & MWX has one feature which I could realy make use of, that being the exception response buffer. So giving the MRX & MWX just a bit more...(don't lock it down so tight) along with the much needed communication response information you've got it.
Speaking of communciation; why aren't the comm registers available to view for port 1 & 2?
Andy,
I've forwarded your request about the MRX and MWX instructions to the proper people at Automation Direct.
Regarding your 2nd request, I need some more detail or an example. What type of communication registers are you speaking about? Do you mean UART registers?
-
I would like to have the ability to view the retentive memory range settings in the Automation Direct PLC's without having to put the PLC in program mode. This would allow me to check to see if the ranges are set properly without having to shut down a process.
-
I would like to have the ability to view the retentive memory range settings in the Automation Direct PLC's without having to put the PLC in program mode. This would allow me to check to see if the ranges are set properly without having to shut down a process.
Yeah, we really need to fix this. I can't believe we let this slip (sorry!). Offically, it's case 1353 in our issue report database.
-
It would be nice to get rid of the 9999 BCD limit on contacts |>=| and |<|. Have the contacts work with real numbers. Converting between all these number systems is driving me crazy. How about everything just works with real numbers, one number system, that's it.
-
It would be nice to get rid of the 9999 BCD limit on contacts |>=| and |<|. Have the contacts work with real numbers. Converting between all these number systems is driving me crazy. How about everything just works with real numbers, one number system, that's it.
We're definitely looking at doing some cool things for Rel 6, like allowing comparison of reals and ints (even mixing them), and allowing you to enter numeric constants as decimal, hexadecimal, or real (even octal), YOUR choice.
-
BCD is for geeks. Integer, float, binary. No other data types are necessary are they? If you simply must have BCD then just use binary and convert it on your calculator(geeky).
Do I really need to tell the processor to load the value to the accumulator before doing an operation on it? Lets move that function to the background where it belongs. I would prefer a math box that could read V4000+V2000*(K3)=V4200
I frequently have to assist programmers doing field work.....it would be very nice if I could access all the same text boxes and such as if I was online...perhaps stopping just short of executing the instruction. Having them greyed out on the menu to let me know they are not available off-line is understandable, but perhaps you could allow programmers to click into them anyway just to be able to talk someone else through it.
I would also really like to see the PID moved to an instruction that could be enabled and disable and as a direct shortcut to the settings.
-
Ask and ye shall receive. Cool stuff in the pipe! ;)
-
Do I really need to tell the processor to load the value to the accumulator before doing an operation on it? Lets move that function to the background where it belongs. I would prefer a math box that could read V4000+V2000*(K3)=V4200
I'm guessing you don't have Rel 5? In Rel 5 we added a bunch of DirectSOFT side instructions called IBoxes, three of which are exactly what you want, MATHBCD, MATHBIN, and MATHR (yes, they do BCD, Binary, and Real calculations on V memory). The Math IBoxes basically generates the LD ADD OUT instructions, just like a compiler would with C code.
Here's a quote from an independent review of DirectSOFT Rel 5 from March 2006, "The real crown jewels are the Math IBoxes"
Check out the review here http://www.plcdev.com/review_of_automationdirects_directsoft5_programming_software (http://www.plcdev.com/review_of_automationdirects_directsoft5_programming_software)
-
Here's a few from outside the box.
Give us the ability to trigger the ECOM test message from ladder logic so the PLC can send us the information on ip address and such.
The ability to format the subject line in an email like we can in the body. That way we can shorten the messages to just from and a subject line
The ability to set the priority flag on the email to high importance
A POP3 client where the PLC can be triggered to read an email account and we can act on the text in the subject line (for being able to reset an alarm from a cell phone by sending the PLC an email). If security is an issue then use the subject line for the password and the body for the text to operate on. Of course the ECOM would have to be able to support username and password to access the POP3 account and then there will be the always present firewall problems......
The ability to send a longer message with a formatted text body so the PLC can send daily email reports.
The ability to generate a ping message from ladder logic to make it easier to determine that the ethernet link is up and running. The present error method does not work if there is anything else wrong with the ethernet link (found out the hard way).
How about a new beta release of firmware for the ECOM100 to play with.
That should give you something to work with for a while.
-
The ability to label sbr constants and display the label in the gts box would be extremely helpful.
Many Thanks.
BD
-
Two needed improvements in data view:
1) Add a column so that the address and label can be displayed simultaneously. Currently they cannot.
2) DS needs the ability to read a subset of data values in (nearly) real time.
Thanks,
BD
-
1) Add a column so that the address and label can be displayed simultaneously. Currently they cannot.
This setting is available in the Data View Options dialog. Right click on a Data View and select the Options... menu item. This will bring up the Data View group of option dialogs (Display-1, Display-2, Doc, and Mode). Select the Doc tab. Check Element and Nickname (and/or Wiring Info and/or Description). Also above the tabs, check the Apply Options To... Current View AND New Views. If you have more than 1 Data View currently open, you can check All Open Views too.
This will display whatever element documentation along with the element.
-
Thanks Franji1,
After using DS for 14 years, I had forgotten that option was there.
I guess the reason I never use it is that the over/under implementation is too wasteful of precious screen space. Columnar display would allow twice as much data on screen.
Data views are nearly always on a laptop, where screen space is at a premium.
Regards,
BD
-
Thanks for the opportunity to express some ideas. I haven't seen some of the latest so I don't know if these are repeats. But
1. Being able to have redundant processors.
2. Redundant highways
3. Hot swappable I/O.
Thanks,
Carl
-
So it has been nearly a year since this question was first posted. I'm sure many of us are curious about how development is going - will we see an expected feature list for version 6 soon?
-
Hmmm, how much should I say? ???
Ok, here's a little tidbit I'll toss out. We are actively developing a new controller here at Host, but the specifics of which I am not at liberty to share yet. It's fast. It's cool. It will represent a link to the past, but also a bridge to the future...meaning...it isn't just more of the same, but a whole new breed that is respectful of the legacy. Every bit of input we receive from this forum is considered for current and future features. We are very excited about it...I would soooo very much love to talk features and schedule...but there is still too much unknown. So until we have a better sense of when this will hit the market, I simply cannot say more.
So, as for DSP6 itself...it is substantially about the new controller. I can't really talk about one without talking about the other.
Please, PLEASE, PLEASE do not call AutomationDirect and start asking about it. They don't know anything, and wouldn't tell you if they did. I am just offering this as a glimpse into the reasons for the questions, and sadly, the reasons for the silence.
When we have a more formal release plan in place, I will announce it here.
In the mean time, please keep your ideas coming!!
-
One thing that I would like to see in a more advanced controller is complex data functions. Seems like the trend is to handle more data. Like running average calculations, sorting and statistics. Omron and AB have some of these instructions and makes the job easier. Also would like to see Standard Deviation, Min and Max,too. I have done Sorting and Std Deviation in AD PLC's and it get's involved. It would be so nice to have 1 box instruction do the whole job at optimum execution rates.
-
One thing that I would like to see in a more advanced controller is complex data functions. Seems like the trend is to handle more data. Like running average calculations, sorting and statistics. Omron and AB have some of these instructions and makes the job easier. Also would like to see Standard Deviation, Min and Max,too. I have done Sorting and Std Deviation in AD PLC's and it get's involved. It would be so nice to have 1 box instruction do the whole job at optimum execution rates.
We've been investigating these. We are thinking of implenting two groups of statistical instructions. One that maintains the Sample data in a large table, where the data size grows as you add samples. And another one that just maintains the accumulation of count, sum, sum of squares, and running min/max, but no actual data values, similar to how your calculator does statistical operations.
The former can provide useful information like quartiles (including Median), sorting, histogram/bin type functionality, in addition to avg/std.dev./min/max. The latter can give you basic average, std. dev. and min/max, but not median/quartile type functions where you need the whole data-set.
With the former, we could also allow you to do running average, or even calculate average on a subset of data points. We could also store the current date/time stamp with each sample value and do time-based statistical analysis (just thinking out loud).
Obviously, the former requires more memory since you must maintain ALL data points, and the latter just requires a few memory locations for as large a sample as you like.
We initially preferred to implmenent only the latter since it occupied the least amount of memory, but then realized, as you stated, that people are doing more and more data analysis IN the PLC as memory is cheaper and cheaper, so we thought, rather than CHOOSE which ONE we should implement, why not just implement BOTH.
One issue becomes, how do you distinguish between the two sets of functions? What mnemonic do you use for the Table/Sample based AVG versus the accumulation-based AVG function? TAVG/AVG, TSTD/STD, but just TQ1 (there's no Quartile function for the accumulation based stat operation)???
Questions? Comments? Concerns?
-
I agree, I believe there are valid uses for both types. Can't wait to get my hands on them. I also would expect the calculations to be quite intensive and would prefer that they be multi-scan instructions with a done bit when the calculations are complete. For Naming conventions, why not use a number system like AVG1, STD1, MIN1 would be Table functions. Then AVG2, MIN2, MAX2 would be Non-Table Based. This also allows any future additions. Just a thought.
-
I agree, I believe there are valid uses for both types. Can't wait to get my hands on them. I also would expect the calculations to be quite intensive and would prefer that they be multi-scan instructions with a done bit when the calculations are complete. For Naming conventions, why not use a number system like AVG1, STD1, MIN1 would be Table functions. Then AVG2, MIN2, MAX2 would be Non-Table Based. This also allows any future additions. Just a thought.
The SORT would DEFINITELY be a "non-blocking" operation, i.e. it would be done across multiple scans. The other Table-based stat operations COULD take a long (e.g. calculating average w/1000 data points), but there are some tricks we could do there. But, yes, we have also thought about those issues too! (great observations!!)
One bad thing about all this, we are looking to push these stat functions out to "Rel 7", not in Rel 6 :'( Maybe we could get the accumulation ones in (they're simpler than the Table ones).
-
While on the topic of sorting. Typically, I have the need to sort a database in Vmemory.
There is an ascii string (Part number) in the first several Vmemory locations of each record. When I do the sort, I have to move the entire record. So when you design the sort instruction, I need someway to be able keep track of these records, either a sort that moves all of the records around or a way to keep track of an index. Perhaps specify a total record length separate from how many memory locations to look at in that record for the sort criteria.
-
Yes, another good observation!! We need to somehow relate data rows, say in a simple case of data and a date/time stamp, such that when you sort by value, its date/time stamp moves accordingly, or if you sort by date/time stamp, the data moves accordingly. Also, we would need to support more than 2 "columns" per "row". As to the mechanism of how you define rows and define columns, THAT is why this stuff is being moved out to Rel 7 (too much other new stuff already planned for in Rel 6).
I'm into triple digits with this post! #100! woo hoo!
-
Could you allow simple math in a compare instruction?
ie. V2000 < V2001 + K10
I use a lot of Analogs ins with Digital outs, This would take tons of lines as well as pointless v-mems (V2002=v2001+k10, v2003=V2001-k10) out of my code.
Also, I know it's been said a lot already, Give me a DL06 w/eithernet and USB native. I'm putting an ECOM100 on almost everything I do. And RS232 style Serial ports are becomming obselete. Try to find a new laptop with one. Or a barcode scanner.
Also, I've used a Magelis HMI that has a really cool Webgate feature, on the shop floor we have PCs all over the place, give me a webgate like that on the PLC and I can forego the HMI altogether.
Thanks
-
OK, for a different area of new features wanted, I would like to see the T1H-CTRIO fixed so it could be used as a DeviceNet slave. I like the Hx-CTRIO series, and would like to be able to use a T1H-CTRIO as a counter with my DeviceNet networks, but the note on Automation Direct's website still says "New product, currently only supported by T1H-EBC, T1H-EBC100, T1H-PBC. Please call for ordering.". It seems like it has been a couple of years at least now that it has been out, and the HX-CTRIO manual says that it can be used in DeviceNet systems, but the A.D.'s website says differently. Since the counter function is done locally in the CTRIO, and it is obviously fast enough to work with an Ethernet or Profibus system, why not a DeviceNet system?
I hope that the new controller that you are talking about in a previous post is a DeviceNet scanner for the Automation Direct product lines of PLC's. Yeah, I know, you can't talk about it. I talked to the techs at Automation Direct about 5 or 6 years ago on a visit to Automation Direct, and they said that there had been discussion about producing a DeviceNet scanner, but nothing concrete had come of the discussions.
-
Terminator DeviceNet? Well...we didn't build that one, which is at the center of the issue. Koyo built the T1K-DEVNET, and for reasons I am not fully aware of, was not able to support the T1H-CTRIO. It may have been related to the size of the memory map...the CTRIO's is quite large...but perhaps another Hostie would jump in and confirm that.
As for the 'controller' I was referring to...no, not DeviceNet...sorry. By 'controller' I meant PLC.
On that subject...how many folks would like to see the new PLC I was referring to available on Terminator? I'm thinking that request is in this thread somewhere, a page or two back, but by a show of hands, how many of you like that idea?
-
Thanks. I did not know if the T1H-CTRIO DeviceNet issue was on a "to do list", and if it was a firmware issue in the CTRIO card or not. I didn't know the problem was on the T1K-DEVNET end.
-
I would like to see the rung comments stay with the rung where it's originally placed at. Our rung comments can get pretty messed up at times.
-
I would like to see the rung comments stay with the rung where it's originally placed at. Our rung comments can get pretty messed up at times.
That, my good man, is a bug :-[. Believe it or not, it SHOULD stay with the rung :-[2. We've been chasing after these since Rel 1.
Make sure you have the latest and greatest maintenance release (available for free from our website), along with possibly re-creating your project by completely exporting the program (using the File->Export->Program... with comments and element documentation), and creating a NEW project from those text exports (using the File->Import->Program... dialog), then you will have a "pristine" database for ladder comments and element documentation.
We've seen a great reduction of corrupted databases since we started shipping Rel 5. That doesn't mean corrupted databases have gone away (i.e. projects created before Rel 5), but we're hoping that if projects created NEW with Rel 5, then THOSE are stable (we think ???)
-
On that subject...how many folks would like to see the new PLC I was referring to available on Terminator? I'm thinking that request is in this thread somewhere, a page or two back, but by a show of hands, how many of you like that idea?
I think that would be great. I presume the CPU would be the same size as the communication modules. There is more physical room for things like other communication ports - Ethernet? How about a flash card for project transfer? What family number would that CPU/IO combination be "205-T"?
-
The CPU would be exactly like the comm modules...same plastic. And yeah, lots of ports.
Flash card is definitely something we'd like to look into. Perhaps not in the first version, but later, as either an upgraded CPU and/or a module.
Shorthand CPU nomeclature would likely be Txx, where xx == CPU type. Like existing 2xx for 250, 260, etc. Part number would probably be T1H-xx, or some such thing.
This has been an obvious one to us for years...nice I/O line like Terminator...could be nicer still with a CPU option. Just wondering if I am the only one riding that train, or if it has occurred to users as well. If enough folks like the idea, I'm pretty sure it can become a reality without much effort. We are already doing everything in the T1H-EBCxxx that would be unique to a Terminator CPU.
-
I asked the question about a CPU for the terminator I/O months ago, glad to see others are saying the same thing. How soon?
-
Yeah, I thought I remembered a request or two for this some time back. We originally pitched the idea to the Terminator product manager several years ago, and got a pretty lukewarm response. Ok, lukewarm is being nice...it was far less than that...so we didn't push it further. I don't feel that it would be a huge volume, but I do feel that there would be enough interest to justify the product. Hoping more folks will respond with confirmation of that belief.
Schedule? Well...I'll say the same thing in regard to a Txx CPU that I said when I first pulled back the cover on Host building a CPU for anything: There is still too much road ahead to make definative statements regarding availability.
I will say this much though, we have functional hardware in house (although for 205, not Terminator), it is very fast, very cool, and does some pretty interesting stuff particularly in regards to data types and instruction simplification. That said, there is still a ton of stuff to do to get this into product form. Once there, there is the rollout process at ADC that can take months too.
And again I'll say what I said before to anyone reading this, pleeeeeease don't go asking at ADC. Since we're building it, they don't have answers, and even if they did, their policy precludes them from making announcements prior to availability.
In truth I would also prefer not to say anything. But, this forum is a valuable source of input for us. Many of the comments have already been integrated into our prototypes, and in some cases significantly altered the design. Given that we at Host do not directly interface with users, except in this forum environment, I have chosen to take a bit of a risk and give you all a glimpse of what is coming.
A very vague answer? Sometime next year. Maybe sooner. Or later. ;D
Hmmm...I just had an idea. In time we will be conducting a beta program and encouraging involvement of a select few very experienced end users....however...I wonder if there would be interest in a members only private forum where we could talk more openly about specific implementation details now. If there were enough folks interested, it might be worth setting that up. At first blush, I think it would be limited to folks that are actively using our products (should be most folks on this forum) who are willing to sign an NDA with Host.
If that sounds remotely interesting, please let me know.
-
In regards to the new CPU, is there a possibility to have run time edits without pausing the CPU? Similar to the way AB & Omron do it. The updates are downloaded and then executed during one scan.
-
We have the bump down to 1 scan + ~1ms in our prototypes. Is that good enough?
-
Oh, so its already included. You guys are on ball. That sounds good, but what are the restrictions? How many rungs or size of the program segment can be changed at one time?
-
It's not a question of size. We basically store 2 different programs, the one you are currently running, and the one being downloaded. You (technically) could do a runtime edit across a 1200baud modem with a 64K program, and it would still "bump" as BobO stated - 1 scan plus about 1ms. The DOWNLOAD/time on the wire may be VERY LONG, but your process would continue to run the old program while the download is occuring.
However, with USB, Ethernet, and even fast Serial, it's not long :D
-
Glad to hear you're going to one-scan online updates.
Other requests:
Master modules (scanners) for popular industrial networks. Slave adapters (Profibus, DeviceNet, etc.) are well represented but the lack of masters is a real barrier to using DL Plc's in projects that mandate the use of devices that don't come in any Koyo networks, or for retrofits where one could just chop off the PLC and install a new one reusing all the old I/O racks. The top of the line processors are plenty powerful enough to do large projects if we could only talk to the I/O.
Better data views and manual manipulation of data files! In a SLC, I can see a couple hundred data values on the screen simultaneously, and write to them simply by clicking on the value, typing in the new value, and hitting Enter. In contrast, in a DL, I have to manually generate a Data View. This has it's merits as well, but with RSLogix, I have the choice of doing it either way (tabular view vs. custom view made from specified registers). Personally, I find I use the tabular view 99% of the time. Forcing is also a pain in the butt in the DL's.
Paramaterizable subroutine calls, and multiple return values.
I also don't like the modal Data and Cross Reference Views, etc. I would like to have the option like with any MDI program of splitting them or having them all maximized and Ctrl-Tab'ing between them. Someone told me that the way it's done now is the standard Windows way of doing it. I don't care, it doesn't work as well. At least give us the option and then the people who like it this way can still have it. Both of them.
Another nice feature is the ability to drag and drop addresses from one token on screen to another. I find in Logix, the fastest way for me to enter ladder is to hit enter with the cursor on the rung, thus opening a mnemonic window overlaying the ladder window, type in the structure of the rung sans addresses, then drag any applicable addresses that are available from other rungs visible on screen, then fill out any remaining ones manually. To be fair, your graphical ladder entry (Ctrl-arrow, Ctrl-Shift-arrow, assumed contact, assumed "C", "/" to change NO <-> NC, etc.) is MUCH better than RS's, so the fact that they have these other options is partly making up for what you have that they lack. Even so, I'm greedy and hope to get the best of BOTH systems!
Also, the hideous button icons. It's not like you haven't had time to do nice ones; the Directsoft 4 ones were much more pleasant.
-
64k of program space? I hope that this was only an example and that you are planning to have much more than that in program space.
-
We haven't finalized that yet, but at 64k we'd be 4x the size of the DL260. Given that enhancements to the instruction set will significantly enhance program efficiency, I think you'll be hard pressed to fill it.
How much were you wanting and why?
-
The 64k suprised me for several reasons:
1. I was comparing that to the AB Compact logix controller. Perhaps, this was wrong of me to do so. If this CPU would have similar features to that controller, the memory size in that CPU is 750k to 8 meg. If this CPU has the configurable tag and program module style layout as CL then it would tend to have larger programs. 64k is far off from 750k. Of course their price tag is way up there too.
2. I don't know what the data area size was going to be, but comparing it to past AD CPU's, it is ususally about the same size as the ladder.
Some major complaints I have from some of my customers is that they have run out ladder or recipe data space. These are small to medium size complex assembly machines with 100's of part numbers. They have reluctantly switched to CL for some of these reasons.
3. New CPU's don't come arround very often and this one has to be able to satisfy your needs for several years to come. Comparing the leaps seen in the PC environment in memory sizes, I expected more of a jump in memory size. Of course, I don't know what your price/performance constraints were, what PLC market you were aiming at or if you wanted to stay in the same memory range as current AD CPU's.
-
Sorry if I mislead anybody. The 64K is 64K instruction words. I'm guessing when quoting memory, people assume bytes. I was referring to program memory and (improperly) assumed everybody knew the units were ladder words (most instructions are 1 word, but others are more). Therefore, program memory in terms of "bytes" is (for now at least) 256K Bytes.
Data is a completely different story. That is usually given in BYTEs since some areas of memory are bits, some 16 bit words, some 32 bit words, others are groupings of common data for a single "entity" (think PID structure in the current ADC PLCs). Data memory does NOT come out of this ladder program memory - there is not a common "pool". Again, apologies for not going into enough detail.
-
So how data memory is there to be? Or is that firmed up yet? I agree that I hardly ever hit the limits of ladder memory size, but like the other poster I like to store recipe data in the PLC and total data memory is usually what dictates the limit on how many recipe slots I can give them.
-
So much is already real, but a few things are still speculative. Some things are simple reallocation of available resources, and some are architecturally limited. Without going into detail, there will be four types of memory: ladder, documentation, image register, and bulk storage. Ladder doesn't have many limits, other than the need to maintain two copies for runtime updates and what is reasonably useful. Documentation doesn't really has practical limits either, but will be set to what we thing is reasonable. Image register has architectural limits, but will be plenty bug...considerably larger than current systems. Bulk storage...suitable for use with recipes and such...will be huge by comparison.
The key thing is to understand that bulk storage doesn't require the level of performance that ladder or image register does, and image register has other factors like battery life and access speed that must be factored in. When people look at the size of a USB drive or gigabyte ram, they immediately think that all memory is free. Problem is that there are very specific criteria for building a PLC and a ton of trade-offs that are not at all obvious. Yes, dynamic rams are huge and reasonably fast...but you can't keep them alive for 6 months on a button cell. Fast statics (cache ram) are blazingly fast, but can't be held up with a battery for long periods. Battery backed statics can be held up for long periods but are small capacity and slow. Anyway, you get the picture.
It does help us to understand what you are running out of and why. Where certain things are arbitrary, we'd really like to give you what you want.
-
What is the form factor? An earlier post suggested this is a new processor for 205 series racks. Is this so, or a new system from the ground up, including mounting and I/O? (Or both, a new system plus retrofit processors as well) Also, if you get a chance, could you speak to the items I mentioned on page 6 of this thread?
-
Initial is 205. Also planning version for Terminator. A new platform will be dependent on market response, but is certainly being considered.
We are still not wanting to publish specific features yet, but I'll say that some of what you mentioned is definitely going to be included. We have placed considerable emphasis on strong data typing and program modularity. This control engine will be a significant step up from previous DL CPUs, but hopefully will be familiar enough to most users to be an easy transition.
-
You've definitely whet my appetite! Don't worry too much about ease of transition; just make the best tool you can and I promise you we'll figure out how to put it to use!
Oh, another thing: symbolic constants, I guess you could call them. In the old TI5x0 and 5x5 days we called it K-memory. Registers which would hold a number which could only be set at program time and could not be altered at run time. So a constant, but referred to by register location. This helps program clarity vs. literal constants, expedites changes if the same constant is used in various locations, and is good for "machine description constants" that are necessary when subsequent machines are qualitatively but not quantitatively identical. Identical operations but need to know the length of the machine, or number of processing stations, etc.
The SLC has the rough equivalent of this if you set the protection for a given data file as "static" meaning it cannot be altered either by the processor or by a terminal or MMI remotely.
I once asked a RS tech guy how this could be done in a CLx and he said to set up a variable and load it with the desired value. I asked him if he saw any problem with advising me to use a "variable" when what I was looking for was a "constant". He didn't see a problem.
-
Speaking of Data Types. One powerful feature in CLx that few programers probably take advantage of is the ability to create your custom data structures. When used in the right circumstance, this is a great feature and can also conserve memory space. One instance being that I had to handle a large array of string variables. The standard size for a string is around 80 bytes, but I only needed strings of 16 characters. So I set up a custom data type that consisted of 25 small 16 byte strings along with other mixed data types. Then I was able to create a large array of this data type. If I were not able to do this, it would have used a great deal of storage space with the default string size. Perfect for recipe creation. Is something like this going to be available?
-
Not to hijack the thread but I think CLx fails to realize the potential of it's vision in several ways. Supposedly a motion platform, you can't put AXIS's in user-defined data types nor put them in arrays. So you can't have Hoist[this].Velocity or even Hoist[3].Velocity. Array indexing is also somewhat hobbled by the fact that you can't do Array1[Array2[n]]. Sorry BobO, I know you didn't set up this thread for us to talk about other products! ;-)
-
Yeah, but in a way I did. The point of this thread is to provide us ideas on how to proceed with new product development. I would say that one of the better ways is to understand what the competition did poorly.
Motion is clearly something that we haven't done very well. That it something we'd like to change in the future, driven by the new control engine. I love to hear more thoughts on that over time.
Interesting thought on K memory. That is one of the more cogent explanations for why you need it, although I confess until now I couldn't have told you why it was a good thing. You use K memory like we use 'defines' in C parlance. Don't know if K memory is the best implementation for that, I think we could come up with a 'define' mechanism that would do the same thing.
Thanks for the input!!
-
I actually have always thought of them as C #DEFINE's. Great minds, I guess. The only situation in which I can see any advantage to having K-memory vs. DEFINE's is if another programmer comes along without the PC version of the code and uploads. I assume the DEFINES would get converted to the constant on download and a virgin upload might show them as literal constants vs. symbolic ones. OTOH, might be good for "know how protection"!
-
Oh, yet another thought (YAT). I like the AB flat-memory approach to PID loops. PID is just a ladder instruction like anything else, and you can have as many of them as you have room for the data blocks. I've run into the PID limit on AD PLC's several times or had to select a processor by how many loops it would support.
You blow those guys away with the built-in tuning screen, though. I agree with the other guys about the desirability of having the trends continue to acquire and log even when a different loop (or no loop) is being viewed. I realize memory might become an issue if you just by default did all the loops all the time, but maybe more fine grained manual control of the operation. Maybe let us choose a couple loops and maybe even tailor depth and acquisition period to trade off between memory utilization and number of loops trended.
-
The new PLC will store essentially everything necessary to regen the full offline project, so one way or the other, we will find a way to get back to the original symbolic constant. We already brainstormed a bit and have a very workable plan. The question with most of this stuff is whether various features will be in rel 1, or 2, or 3 of the new control engine. Unlike previous controllers, we are moving to a view that the controller is nothing more than MIPS and megabytes, and that the control engine itself upgrades with the DirectSoft version.
Our current PID implementation is exactly as you describe, and you still get the loop tuning tools...although they are a bit different (and simplified) from the original DL implementation. We are using a more 'tinker toy' approach. Alarming in all forms, and ramp soak, filtering, etc., are all separate instructions. Rather than trying to create a single very complicated instruction, we chose to allow folks to stack just what they needed and keep stuff very simple.
As an example of what that buys us: You will be able to create a new program, add a couple of simple rungs, download to the PC-based control engine simulator, turn on the Sim's built-in FOPDT process simulator, pull up the PID trend view, and autotune the loop...in less than 5 minutes. Cool huh?
-
Not just cool, but...WAY COOL!
-
Massive kudos on nimble response to customer input! AB can't even blow me off that fast.
-
To ATU...regarding your question about custom types and such: The short answer is 'yes', although perhaps not until rel 2. We already have structures working, and there is no good reason not to allow customer created types....however...the type editor and user type management will take some additional work that we may not be able to get into the first release. We already have two string related built-in types SS and SL: short strings (up to 64 chars) and long strings (up to 256 chars). In thinking about what you said, we arrived at the conclusion that allowing customers to create string blocks of arbitrary lengths would not be difficult. Meaning....if you wanted a whole bunch of 12 byte strings, we should be able to accomodate that when we add user created structs.
To Controls Guy...regarding array indexing: Sadly, our array limitation is also limited to depth of one...you can do Block[Vn].Field, but not Block[D[Vn]].Field. Not sure how we'd get that into our implementation, which is still just a conventional PLC....not a compiler.
-
Hmmm...let's see if we can create a real panic.
The attachment is a months old screen shot of the PC Sim with the FOPDT process simulator open, along with a trend view of some PID loop goodies. That is not the PID view, which is a whole new view based on the general purpose trend view. The new PID view wasn't complete at the time I grabbed this screen shot. Everything you see here, along with 2 rungs of the ladder code, can be set up in a few minutes.
-
Looks nice. Thank you for putting Parameter explanations right there where you need them. I have a difficult time keeping it all in my head and just being able to access that quickly is very helpfull.
Back to the Data structures. Will you be able to monitor and change real time values in the variable data table or will you have to create a Data View to be able to that? CLx has a Monitor/Edit tab which is handy, however they don't make it a tab viewable with your programs. It makes it difficult to switch easily between the program and the variable list and you have to go upto the Windows menu to select it or select it from the tree. Also you don't have a choice of selectively monitoring what is in the list. It's either all or nothing. If you have a lot of strings, it bogs down the monitoring update noticiblly when viewing that part of the data table.
I would much rather have 1 list on a Tab with your programs that you can edit/Add/Delete and with a simple check box to turn that variable on for monitoring. Maybe have a check all or uncheck all at the top of the column.
By the way what is the difference between D and R memory?
-
Wow - this is really getting exciting. I know you guys (and gals?) are excited because you are controlling both the CPU and the programming package. I just hope you're not trying to adopt so many features at once that the project won't ever be released.
-
Bernie...we are trying to do no more than is absolutely necessary in the first release to get the critical infrastructure defined; so much becomes harder after we release. The challenge is sorting what needs to happen now vs what can happen later. That said...yeah...we ask ourselves the same question weekly.
ATU...yes, individual fields can be changed. Currently that happens by data view...but...we are kicking around many great ideas for making that process easier. Please see answer to Bernie for clues as to why stuff might slip into rev 2 or 3. ;)
-
Oh and ATU...D memory is 32 bit signed int, whereas R memory is 32 bit float...all part and parcel to the strong typing we have mentioned. The Sim just includes a handful of values for display to make for a nice demo and tutorial tool. Notice the WX and WY types...analog ends up there without further work on behalf of the user...and may be familiar to TI5xx users.
FYI: There are many more built-in types that aren't included in the Sim display. ;)
-
Totally understandable. You have to draw the line somewhere or you will never complete the 1st release. However, these thoughts sift from my head and I have to get them out and written down when they come to the surface or I will forget. I've worked with many different programming packages and trying to relate what I think are the best implementations and what I would like to see. I don't expect it on the first release, but perhaps if you come across a good idea, you don't want to set something in stone where a good idea can't be realized in the future.
-
Bring `em on! This forum becomes a great place for discussion...and archival...that we can refer to in the future when we are looking for new stuff to do.
The problem that we are currently having is that by owning both ends of the pipe...the CPU and programming software...we suddenly find ourselves with a power tool we never possessed before. The first part of that process is to free our minds of previous limits (aka...'there is no spoon') but then once we have freed it, bringing that to a sustainable development plan. The freeing was pretty easy, but the second part...not so much. The question we constantly ask is whether the proposed development affects infrastructure or not, and whether it is easy now or not. Easy now, and we might do it. Not easy now, but not infrastructure dependent, we'll do it later. Infrastructure dependant, regardless of ease, is getting done now.
A great example is our current plan to support modularity...including call-able functions and such. We know what needs to happen, and are going to put all the infrastructure in place, complete with automated testing of required instructions...but...some of the required UI to do it right will have to wait until rev 2. Which means that as far as the user is concered, it really won't be there. But it give us a great confidence that we haven't painted ourselves into a corner with things that are so easy to change now, but are painful...or impossible...later. I hate it, but stuff like this will hold up initial release. But you'll love us later!
-
Woo hoo! No more futzing around with the pointer method or multiplexing!
Don't forget the enhanced tabular data view (many values per screen).
-
All this looks Great ;D! I just hope were not looking at an AB price tag when it's all done. Thats what knocks out the little guy like me :-\ BTW The PID trending/tuning looks great! Are you changing the PID trending for DS or is this only for the new controller? Thanks
-
No, the existing DirectLogic PID view will remain the same. The view in the picture is actually just the new Trend View which will be a feature in the new controller, at least initially. There is also a new PID view (for the new CPU) but it wasn't complete at the time that I took that screen shot several months ago.
We may retrofit Trend View into classic DirectSoft...but, it may have a few limitations. The new CPU is strongly typed, and the new programming environment makes big use of that fact. Since the existing controllers are not strongly typed, it becomes necessary to add some additional UI and back-end complexity to deal with type management.
Price? Trust me, you'll love it.
-
So it sounds like there will be separate programming packages for the new and "classic" controllers rather than this being "DirectSoft 6.0"?
-
We like to think of it more as DirectSOFT being different between the 305 family as compared to 05/06/205/405 family. The PLC submenus are different between the PLC families, the instruction sets are vastly different, but the basic editing and UI are similar. So as much as 305 and 05/06/205/405 are "different packages", then the answer is "yes". However, there are still a lot of similarities.
I know that makes it clear as mud! ;D
-
Uh...ok...I think. So will I have to purchase, install, and maintain two programming packages or will a single new package program all PLC's including the normal stuff (05, 06, 205 'classics', 405's), the 305's, and the new, '270 Super' or whatever?
-
Uh...ok...I think. So will I have to purchase, install, and maintain two programming packages or will a single new package program all PLC's including the normal stuff (05, 06, 205 'classics', 405's), the 305's, and the new, '270 Super' or whatever?
We eliminated the separate packages with Rel 5. You used to be able to purchase a BRICK ONLY, or a 205 ONLY or ?? ONLY. We are hoping to stay away from "separate" packages (it sounds like you would agree), but you'd be surprised how many people look to save a buck here or there and WISH there would be, say, a "270 ONLY" package (or whatever). We ended up with people with Rel 2, 205 ONLY and a Rel 3, 05 ONLY, complaining when they bought the "upgrade" for Rel 4, that it could not program an 06! Guess what you get when you upgrade a 205 only and an 05 only package - a package that can ONLY program 205 and 05!! Rel 5 only comes in one package - you get it all. Host bit the bullet and when you upgraded ANY previous "ONLY" package, you got to the FULL package for Rel 5. We really want to stay away from that mess! :o
I really don't want to discuss any marketing now anyway (it's WAY too early). :-X
-
What Mark was saying is that DirectSoft is pretty much 2 separate packages already...crammed into one application. Nothing is formal, but our intention is to continue the trend of having all PLCs programming with 1 'package'...with 'package' being the important word here. The programming environment will likely be more loosely coupled than previous versions, but will likely be part of a single DirectSoft 6.0, upgradeable as usual. The new controller is enough different than existing controllers, that trying to merge environments into a single app was looking dang near impossible. The most likely scenario is that they will share the comm server, launch window, and other common stuff, but the actual programming app will be different...but amazingly similar.
What Mark alludes to in terms of marketing questions, is that we are looking at the new control engine as having somewhat of a life of its own, independant of the platforms it runs on, and there is some consideration being given as to what that looks like going forward. The short answer is that until we get some customer feedback and market presence, anything we say is pure speculation of future events...aka...fiction. We try not to make plans on the basis of fiction, but as times cannot help but ask and predict and make plans...that we usually get to change. ;)
In some ways, I really hate opening the kimono this early and leave you guys (and gals?) feeling jerked around...but...I hate even worse developing in a vacuum and not making use of the talents and experience of our customers. This topic has started wandering into a bit deeper waters. We really should get some of you under NDA and start a private forum for the more intimate details...
-
Please.........whatever you do, keep the kimono closed! :o More intimate details would be welcome, as long as they don't involve the kimono.
-
Nice reading all the good stuff coming in the near future. Where does price fit in all of this? Since the old stuff will still be around, it is nice to see new stuff coming out. Can not wait to see what AD does with the programming languages. The one thing that got our attention here was the price. For instance the Allen Bradley HMI is $3000 compared to C-More at $800. There PLC,s cost way more than AD. And the AD ease of use is unbelievable. We had a vendor come over and demo, we said no thank you. What took him to do in hours with AB we did in minutes with AD. He was surprised. There is not much we can not do with a AD plc. I was reading here customers running out of room for recipes, we have not experienced that yet. AB does do good with motion control, but we do not use AB motion so we do not need that in a plc right now. There are so many Servo Vendors out there, we found two we like. And they interface well with AD. The servo systems we do use, dont require a PLC, all is built into the drives. They have a computer controller so there is no need for a PLC. Keep the good stuff coming. AD your doing great.
-
1. double word comparitive elements would be very nice.
2. a way to list elements that have been named but are not used. as i edit and trouble shoot the code i seem to have elements that i don't use anymore. since they are named i don't reuse them. it is just too time consuming to go back to the ladder and do a search.
-
@PLCGuy: Sorry not to have responded regarding price...I really can't comment specifically yet, but trust me, you'll like it. ;)
@Missouri100: #1 is a done deal and #2 is a great idea. Not sure when we'd get #2 implemented, but I think we'll do it eventually.
-
What about comparitives for string variables?
A = B Strings are identical
A > B Alpha-numeric sort, String A would proceed String B
A < B Alpha-Numeric sort, String A would follow string B
-
String processing is an interesting problem in a PLC. We definitely want to do it right, and plan on putting some considerable thought into how to do so. My instinct tells me that string handling is probably best handled by a high level BASIC-like or ST-like language, but as we get a little closer to that point...probably not the initial release...we'll have a better sense of how to do that right. Certainly comparison functions or operators would be a must in any complete implementation. I'm sure we'll use the forum to gather input when the time comes.
-
2. a way to list elements that have been named but are not used. as i edit and trouble shoot the code i seem to have elements that i don't use anymore. since they are named i don't reuse them. it is just too time consuming to go back to the ladder and do a search.
But doesn't cross reference view in usage mode handle that? I often already have cross reference view open in normal mode and just use that, although it's not quite as functional for this purpose as usage mode. But my point being, if it's more trouble to click the button to change to usage mode, normal mode must be fairly functional for this.
I also tend to preplan data memory in Excel, at least in programs that let us do a good import of synonyms [ahem] and assign entire blocks of data, including some spares. I admit that tends to get out of sync with the code unless you update it every half hour, and if you're going to do that you want to make the Excel copy the master and make no changes from the ladder editor.
-
String processing is an interesting problem in a PLC. We definitely want to do it right, and plan on putting some considerable thought into how to do so. My instinct tells me that string handling is probably best handled by a high level BASIC-like or ST-like language, but as we get a little closer to that point...probably not the initial release...we'll have a better sense of how to do that right. Certainly comparison functions or operators would be a must in any complete implementation. I'm sure we'll use the forum to gather input when the time comes.
I'd certainly like to be able to do comparisons in ladder, and move values around that I'm not actually performing any other operations on (like the part name in a recipe), and even do simple manipulation like concatenation or substrings, but when it comes to parsing some string from a scale or something, I'll take the BASIC/ST please.
-
2. a way to list elements that have been named but are not used. as i edit and trouble shoot the code i seem to have elements that i don't use anymore. since they are named i don't reuse them. it is just too time consuming to go back to the ladder and do a search.
We've kicked around the idea of a "Super View" that includes XRef, Doc Editor, Data View functionality in one view, where you can turn on or turn off "columns". With that, it wouldn't be too hard to add some filters like elements in the program, elements NOT in the program but with documentation, et. al.. This last filter would be perfect for your purpose. It would also be cool to sort by element, by nickname, by first address referenced, etc.
However, this view is just pie in the sky stuff for now :'(
-
Oh, yeah, and a Data View that can show hundreds of values on the screen on the same time without the BS columns and without the setup effort. [screenshots to follow]
-
Ok...realizing that I might find myself frightened by the proposals..;)..I'd love to hear your thoughts.
Simple question: If wishes were free, what changes would you make to the DirectLogic PLCs?
We're leaving this wide open, so don't be timid! Post!!
I would like to have an IBox equivalent to A-B's Scale with parameters function
-
I would like to have an IBox equivalent to A-B's Scale with parameters function
Please describe in enough detail that we understand the basic functionality (we're not an A/B shop ;))
-
The box contains an entry for the input location, input min, input max, scaled min, scaled max, and output location. See attachment.
Its much like the current IBOX except it doesn't assume 0 - 4095 as the desired min and max input points. You could do the same thing by thinking about what the engineering unit would be at 0 input and 4095 input but then the whole point of these boxes is to remove the thinking part.
-
Bernie,
Thanks! That's exactly what I needed!
-
1. USB memory stick drive for PLC program save and downloads.
(even if it were and additional hardware program loader device)
2. Additional cost option for PLC programing incorporated into C-more panels. (USB port use again)
3. User defined I-Boxes ( Yes I know who else does it)
4. Maybe to get higher end features into the software, a 2 tier pricing scheme would be acceptable.
(Basic= low bucks, Advanced=more bucks) ( I would pay!)
-
Forgot one more thing
A visual PLC network map to point and click on to the PLC you need to work on.
-
A visual PLC network map to point and click on to the PLC you need to work on.
Can you say "J-Net" ;D
-
I'm pretty sure this has been asked before, but;
Any Linux plans for new releases? I've done a little digging, and as I understand it, getting DS to work on a linux platform is not too much of a biggie, it's accessing the comm ports that is tricky...(?)
But with the Vista comm port issues, and the "fixes" that are needed, would it not be possible to make a flexible or possibly separate-able comms package that you could configure/download according to your chosen platform, when purchasing DS?
-
Linux? Hmmm...don't know much about developing for Linux, but my guess is it would be a pretty tall order. We don't get much expressed interest either. Not saying it would never happen, but we're pedaling pretty hard right now...so no, we have no immediate plans for Linux. Sorry.
-
What about a program archive feature? You can keep the files that you have now for ease of troubleshooting, that is fine. I can understand you have reasons for this. However, I would like to hit a button at anytime and all of those files get condensed to one, easy to copy file at a location that I choose. Also have a facility to reload from the archive. What I don't want is to have to close down the application to do this. Rockwell's Factory talk requires you to shut down the main application to copy, rename or backup the application file. I think they also have a collection of files for the application and then archive everything into a project file. This is really time consuming, however the end result is 1 file that is easy to backup to a USB or Network drive.
-
Working on that now, in fact. The new controller uses a new file format that is essentially a zip of all underlying temp files. We are also investigating a restore point mechanism that would provide a very robust undo function within the current session. Those same files will ge backed up automatically every time the project is saved. With the new stuff, you'll have lots of new opportunities to confusion yourself will old program versions!
-
That sounds great for the new controller. What about the current controllers? Any chance for parts of this feature to be used?
-
That's more difficult. The near term effort to create a new controller, control engine, and programming environment substantially from scratch, is a huge undertaking for a small company like Host. So for now, all resources are focused on the new controller.
Longer term, we very much hope to roll some of the new features into the legacy controllers. Some of new features simply cannot be ported due to the lack of strong typing. And some of the file features are complicated by the fact that classic DirectSoft maintains a level of file compatibility with TiSoft and S62P...other programming packages in use with Koyo controllers. We have made the decision to drop many legacy compatibilities specifically so we could do some cool new things. Engineering tradeoffs are always hard decisions.
But, as I said, we do hope to retrofit some of the nicer features as time and resources permit. Certainly a basic archive function wouldn't be particularly difficult, and we have had plans to move to a single file for years...it just always seemed to get pushed to the 'next' release. We ended up pursuing it now mostly because we had no choice...the existing files formats were simply inadequet to the task. Nothing like necessity to get you moving...
-
"The new controller uses a new file format that is essentially a zip of all underlying temp files"
Yes a simple archive feature would be great. Just being able to create a zip file inside Directsoft while the project is open would be a great thing. What I have to do now is close out the project, create a new directory to put all the files in. Copy all the correct files and hope that I don't miss one. Then copy the directory to my USB drive. It would be so convenient to hit a button and create one compressed zip type file on my USB drive with all the files and I know they are all there. You already have a backup feature. Why not add a checkbox with a compress to one file option?
-
I know this isn't adding much about the new developments but, since day 1 using AD products (or PLC Direct I should say) I always began a new project in its own folder. Thus it was always easy to copy and/or zip that folder confident that I had all the files.
Actually I create a folder for the entire project and inside that a folder for the PLC, one for the display, one for any drive setup files etc. Essentially one folder for each programmable type of device on the machine. The entire zipped folder is easy to include in documentation to the end user.
-
Com'on Bernie, quit cutting the development team slack! Make 'em work for it. Crack the whip! ;)
-
I have the same method for my files. However, everyday I create a new revision of my program under development. The origins being from the early days of directsoft when the database would corrupt so completely that you could possibly end up with unsusable documentation. However, I have found that it is smart to have older revisions to go back and look upon in development. Keeping track of all of those files and directories are time and space consuming. It would be so much easier to have only 1 file to deal with.
-
That's another thing we changed in the new controller...the documentation database is no longer a database at all, it's just a big flat data file that gets loaded into memory. We will be writing to temp files every time something meaningful changes, but not incrementally, always the whole file. Additionally, even though we update temp files following every relevant change, the project file itself only gets updated when you save the project. We are also hoping to be able to recover the project from the temp files if you crash out or dump Windows. It will be much less like the past DirectSoft, and much more like Word or Excel. Hopefully more intuitive, modern, and useful.
-
One thing that I didn't see mentioned (but then I didn't read every post completely) is storing documentation files in the PLC. This has been a wish for as long as I can remember (I've been using DirectSoft since release 2). With memory as cheap as it is, is there really any reason not to store the documentation in the PLC?
-
Nope, and it will.
-
A quick, and hopefully painless question....
Do we have a ball-park delivery date yet?
If so, please enlighten us?
Thanks!!
-
We're not even to Beta yet, so it's gonna be quite a while, but sometime next year.
-
Here are some things I haven't seen mentioned, unless I overlooked something.
1. Iboxes for the internal CTRIO in the PLC. Last year I got so confused with trying to use the internal I/O in ladder, I just bought two CTRIO modules to control the X/Y table. It sure was easier!
2. Analog inputs/outputs standard on the PLC. Many other PLC's (including cheapies) have two channels available for either analog or digital measureent and control.
3. The PLC be controllable as a slave from Labview, either through a USB port or the ethernet.
4. Ethernet a standard feature.
Thanks for listening (reading?).
-
If I missed this in the previous 11 pages, consider it a second to the vote.
The ability to do log functions in the PLC.
-
The ability to do log functions in the PLC.
Be a man. Use the polynomial expansion. :D
-
Logarithms? Or data/event logging? Both are needed of course, just wondered which you meant...
-
Oops...I meant logarithms.
-
Here's one: Ability to verify instruction and address range compatibility with a given CPU offline.
I once had a project where I was using a semi-standard program framework that had been developed for an 06, but the I/O requirements of this particular project was a better fit for an 05. I simply made the program changes and changed the offline PLC config to an 05, and DSoft saved it without complaint, so I thought everything was fine and had been verified to be so. Then when I went to download it (now on the critical path for completion), it wouldn't download because I used instructions not supported in the 05. So I called tech support and the guy insisted that this was natural and unavoidable given that the DSoft doesn't have a "simulator". To me a "simulator" is for verification that your application does what you want it to, not for verifying that it will run on the target CPU. Many other brands of programming software that don't have a simulator (by the definition I just gave) will still warn you if you've done something that won't run on the CPU you've indicated.
If there's no verification done, what is the point of making the programmer tell DSoft what the CPU is? Seems like it would just be busy work for which he doesn't get anything in exchange.
Now memory range verification is quite a bit easier to do manually, expecially on long programs, because you can just do a usage view and compare with the PLC memory map accessible from the menu. But at least instruction verification would be nice.
-
We want to implement something similar to what could be called an "offline syntax check", for lack of a better term. It won't fix anything, but just list every issue that would be determined at download time, similar to what you found with the 06 program in an 05. It could probably also determine many fatal errors that could occur when going from program to run.
-
HAAAA! been a while, a lot has gone on here at the site, and a lot has gone on here for me as well. As for adding new stuff, Don't really do any heavy programming to ask for anything. I would like to see a copy and paste feature as I read someone had posted, that would be nice, for now. What do have for stepper motors on 05's and 06's? Or can that be done?
-
We want to implement something similar to what could be called an "offline syntax check", for lack of a better term. It won't fix anything, but just list every issue that would be determined at download time, similar to what you found with the 06 program in an 05. It could probably also determine many fatal errors that could occur when going from program to run.
Here's a cool implementation idea for that. Allow the programmer to run it on a given program, and let the syntax checker show a list of all CPU's with compatible ones highlighted. This isn't the option a person would generally use, but if you have the syntax checker done, shouldn't take too much more to run it against all available CPU's and show which ones are compatible.
Probably with separate Go/No Go indications for code compatibility and address range compatibility, if addresses are checked.
-
Oh, and another thing! ;D I always liked how in versions before 5.x if you did a DirectSOFT install with an upgrade product key, after verifying the presence of the upgradable version, the install would give you a product key for a full install. Then you don't need to keep track of all your old versions with product keys (or at least the newest full install you have) so you can install the version you don't want so you can install the version you do want. Or, something like that.
-
Feature maybe, bug fix to my mind! Please extend the find functionality into the iBoxes. I haven't taken the time to verify all of the different possibilities, but it is clear that find does not find within the MATHBCD box...
edit to include:
I definitely would put logging within the PLC to use, the more easily integrated with touch panels the better! I know it's been mentioned above, and I wholeheartedly endorse it as well as simplifying the installation/licensing process.
Finally, built-in testing/simulating functionality would be incredible!
edgar
-
I think you will like what we are working on now. I think that in one way or the other, we're doing all of what you asked for!
-
Read this entire thread and the V6 looks real cool, soooo.....any chance we could get a status? ETA? ::)
Jeff in Florida
-
Well, given the market we are in right now, we are highly motivated to get it out this year. There is much left to do, but late this year remains our goal.
-
yet another feature request list:
DS6
- feature required - please add the ability to Find Previous when searching the ladder
- ability to show/hide rungs just leaving a plus sign in it's place with a tooltip bubble for the first two lines of the comment field (useful for all those "setup" rungs we put in our programs)
- Documentation View: filters (eg. jump straight to element categories via buttons such as X, Y, etc.)
- toolbar button bars switchable to Ver4-sized icons
- eliminate the obligatory New Project dialog everytime you open a programming session (people can click New easily enough if they intend to start a project from scratch)
ECOMs
- ability to send larger emails
- program-defined web pages
- enhanced security and configurability for the http server plus configurable data access
DL06
- expansion option or built-in cardslot for web-accessable CompactFlash or USBkey (datalogging). Could it possibly be combined with the ECOM?
Thanks for all the hard work integrating features and the amazing customer communication .
-
Will the new PLC have support for DNP3 Master / Slave?
-
Will the new PLC have support for DNP3 Master / Slave?
Sorry, no. I'm not familiar with DNP3. What types of applications would a PLC be useful as a DNP3 Master? What types of applications would it be useful as a DNP3 Slave?
What is the physical layer for DNP3? Is it RS-232? 422? 485? Ethernet?
-
In DSLaunch, allow the list of projects and links to be limited to those last opened within X amount of time. An alternative is to limit it to the last X number of projects. We produce all custom machines so don't have a standard program. The list fills up quickly and must be weeded occasionally.
Another would be to change the projects list to be just the Explorer tree view of the projects directory. Right now I right-click 'Browse' to open. Just have a version of the tree view already there.
-
I'm with you, Bernie. I find the "normal" way of deleting links in the projects area at once too safe (one dialog per file) and too dangerous (don't accidentally select to erase the files with the link!). I just edit DS500.ini and I get to delete all the links (or all the ones I want to delete) in one swell foop, with no risk of deleting the actual projects.
-
I use the DS500 edit way also. It just seems a little bit kludgy. Of course it's not as dangerous as editiong the registry. Many probably on deal with a few files and don't want to remove them.
-
AFAIC they could just add recent projects to the File Menu like a normal Windows program. They insist on following usual Windows app GUI conventions (having the dockable Xref and Data views not part of the Ctrl-Tab sequence, etc), but when the standard approach is better, we get this. :(
-
Will the new PLC have support for DNP3 Master / Slave?
I'm not familiar with DNP3. What types of applications would a PLC be useful as a DNP3 Master? What types of applications would it be useful as a DNP3 Slave?
What is the physical layer for DNP3? Is it RS-232? 422? 485? Ethernet?
Wikipedia is your friend http://en.wikipedia.org/wiki/DNP3
In our case here in Australia DNP3 is used extensively in the water industry where the PLCs/RTUs are DNP3 Slaves and only report on exception to minimise on overall network loading.
At the moment here in Western Australia, Koyo is uses in the majority of regional pump stations but unfortunately is on the brink of being potentially being replaced by a GE PLC which has DNP3 slave functionality as when a Koyo is installed it needs to be paired with an RTU just to do the Modbus to DNP3 translation. Having support for DNP3 would position the new PLC strongly in the water industry over here as it is extensively used for not just its cost effectiveness, but also its simplicity as far as programming is concerned.
-
So it sounds like DNP3 as a slave is useful in a traditional PLC? DNP3 Master capabilities are not needed? If this is true, then this is good (a PLC is not a SCADA system). If this is not true, please explain how you would set up a PLC as a DNP master to configure a bunch of DNP3 slaves. Normally, comm is done via polling from master to slave, but DNP3 looks quite advanced for a Master to configure what we call "report by exception" requests in the slaves, causing the "slave" to initiate the transfer? This seems do-able on a peer network like Ethernet, but I'm not sure how it would work in a multi-drop serial network, where you speak only when spoken to?
-
DNP3 Master capabilities are not needed? If this is true, then this is good (a PLC is not a SCADA system).
Yes that would be correct as a DNP3 Master would probably be too complex to implement at the PLC level. In our case we would be more interested in DNP3 Slave at a serial level but the way things are going with the shift from serial to IP based comms it would probably make sense to also have support for ethernet as well.
One important thing though is that even though many vendors say they have support for DNP3 it is sometimes not "complete" and therefore its probably important that the implementation to the standard is complete. I believe this is the DNP organisations website http://www.dnp.org/About/Default.aspx
-
We cannot do it now (already too much to get done), but we'll consider it as a possible protocol in future versions. Actually, Host Engineering develops the Ethernet products for ADC, so it would be easier for us to implement it on the ECOM100 vs. a serial port.
-
We cannot do it now (already too much to get done)
thats a shame but i guess you guys are already under the pump. Hope though it does happen in the future as this will give the Koyo a big boost in the water industry over here and also lock in a lot of future implementations.
We are eagerly awaiting the new PLC & Software so bring those out first and lets worry about upgrades and more features later on! We really need the new PLC here to help us knock heads with the big boys (GE, AB, Siemens etc.)
-
Another thing that came up, would there be any form of "redundancy" available?
-
Another thing that came up, would there be any form of "redundancy" available?
If you mean "hot backup", we've talked about it, but that's it. Not sure of the demand (like DNP3).
-
Thanks for your quick responses Jack.
From a marketing perspective at which level do you forsee the new PLC sitting when compared to the competition?
For example,
if we take AB will it sit at: compactlogix or controllogix level?
if we take Siemens: S7-300 or S7-400?
GE: Versamax, RX3i or RX7i?
Just to let you guys know to remove any doubt we (KAPP Engineering) are value added resellers for ADA in Western Australia
-
I can't really discuss the details, but it's not high-end, and it's not low-end. We're leveraging some of DirectSOFT and the Direct Logic line. That's all I can say.
-
I'm currently testing a dl260 system using a dd2-d to simulate conditions. what i've found is that the Click program allows "and above a join" but the DS5 does not. what gives? It seems simple to me, "if X1 and not C3 then Y2 and if not C1 then Y3".
Is it my programming logic style? Could you fix that?
-
That functionality is implemented via the MLS/MLR instructions in the PLC. Please review the PLC manual.
It would be nice if DirectSOFT some day would auto-encode those instructions into the rung style you describe. We've gotten this request before. It's on our "todo" list, but it tends to get pushed down below other "important" features. :(
-
Another point related to mid-line outputs...
It is easy to draw in DSP, but would also require some manageable but non-trivial changes to the ladder compiler. As Mark alluded to, however, there is no direct way to code the logic...the DL controllers simply don't have the instructions to do that. It can be done through MLS/MLR, but the use of such could cause issues with the hand-held programmer, or more likely, the hand-held would cause issues with us.
That is something that we would like to sneak into our new controller, and we think the logic could be pretty easy, but the changes to DSP are more than we want to commit to for release 1. That is a fairly high priority thing for future releases, however, and we do expect to get it in eventually.
-
Hi,
I think this is a feature request (unless the technical support at AutomationDirect was incorrect with what they told me). I would like to see real bumpless transfer in the DL PLCs. I have tried this in the DL05 and 06 and assume all the DLs do the same (maybe not), but bumpless transfer is not bumpless when there is an error between the setpoint and the process variable (trying type II bumpless).
Here is my scenario:
I have a fast (e.g. 5:1) proportional gain and a very slow (e.g. 5 minutes) integral in my PID loop. I'm in manual mode with my output at 50% and I change my SP to 75% and my PV is currently 25%. When I change from manual mode to automatic mode, the controller should (depending on direct or reverse acting) start at 50% output and slowly start integrating up the output 50.1%...50.2%...50.3%...etc. Try this with any controller (other than a DL) and this is exactly how it will perform (bumpless transfer).
While changing the SP to equal the PV (Bumpless mode I in the DL PLCs) will essentially make the transfer bumpless, that isn't what I want, I want the SP to be what I set it to. With the current DL PLCs, there would be a huge jump in the output in my scenario because of the error between the SP and the PV and the high proportional gain setting. The way I understand the manual, the way the Bumpless Transfer II works is by writing the current output to the bias value in the PID upon transfer. This should also include the current error calculation between the SP and the PV to have the transfer be truly bumpless.
This change would be greatly appreciated and bring the DL PLCs more in line with the competition.
Thanks,
Mike E.
-
Yep, you're in the right place.
This topic is being used primarily for folks to let us know what they want, but since we have no control over existing DL PLCs, we are using the info to help shape the new control engine and PLCs that Host is developing.
We are definitely not PID experts (although I can spell PID and have stayed at a Holiday Inn Express ;) ) and would welcome any feedback (yes, pun intended!) that you can provide to help tune (*rimshot*) our implementation.
Seriously...we'd love your help.
-
Mike E.
When I change modes on my loops, I write my own bias values. You can add the error to the bias in ladder and write it back to the Loop Table Starting Address+4 and it is read-on-the-fly. That was my workaround. If it was built into the loop setup though it would be nice.
Jason
-
That's sort of what I do. I don't even bother using the PID's internal manual mode.
-
OK...let's make sure I understand...
Normally, this happens at manual to auto transition:
if(PositionMode)
PID.Bias = PID.Output;
And during a normal auto update:
PropTerm = ...Calc PropTerm...;
PID.Output = PropTerm;
PID.Bias += ...Calc IntTerm...;
PID.Output += PID.Bias;
The problem is that with a big error, the proportional term rocks the Output, yes?
So, you want this at manual to auto transition:
if(PositionMode)
{
PID.Bias = PID.Output;
PID.Bias -= PID.Gain * Error;
}
In essence, just subtract the proportional term from the Bias so that the proportional term plus the Bias is equal to the original Output, yes? From that point, the only change to the Output would come from the integral term, or further change to the Error.
Am I understanding?
-
That's what I took the OP as requesting, BobO.
-
In Layman's terms: As the PV fluctuates around the SP, the Output fluctuates around the Bias term. So if, while there is a huge difference between the SP and PV, we bring the Bias term (Bumpless transfer II) to equal the current output; then the next output will create a huge bump, because the huge error that the PID calculation produces will be added to the bias term, which is now (in Mikes example) at 50% of the full scale output. The only way the process can remain steady is for the bias term to equal the current output (50%) minus the current PID's calculated error(not the error between the SP and PV, but the error that will be added to, or subtracted from, the bias value). This may be exactly what Bob just said, but this is my understanding of the problem. :D Jason
-
That is pretty much what I described. We essentially zero out the integral term and offset the proportional term, and the derivative term will be 0 anyway. That means that unless there is a change to SP-PV, the only change happening at the first automatic update is the integral term as it integrates error. That should produce a nice smooth transition. Might be so smooth one might call it 'bumpless'. ;)
-
Add in the feature to Directsoft that when you print out the cross reference table you get a graphical image (and, or, etc..) along with the boolean command.
-
Bob, I've enjoyed this discussion very much. Lots of good suggestions from folks.
I like the DL205 series, and it's nice to read of a new processor upgrade for it. Ethernet on board the cpu module would be good, as it would reduce the price.
I'd like to see more I/O module meta data....but let me organize my thoughts before I make any specific suggestions.
-
Any updates on the DL270 CPU?
-
Nearing beta now. Looking awesome. Fast. Seriously cool new features. The new DirectSoft that programs it is a big jump over 5.0. You will like it very much...I promise it will be worth the wait. I'd post a screen shot or two, but ADC would have my head. ;)
Current target is late Q1/11.
-
First off, let me say that this is just an excellent programming package. Overall, very feature-rich. So by bumping this thread again I'm just hoping a few other feature enhancements may be included with Ver 5.4, (6.0?)!
I realize that it's trivial to ask and difficult to include, but you folks at Host have been amazing in the past.
This may be too late but since a release may be impending I'm looking forward to the possiblity of:
- Search "previous" as well as "next" in the ladder.
- In Doc editor, "shortcut" buttons to jump to various blocks in memory.
- Option to display a Data column in the Doc editor. Not necessarily editable but an option to display data maybe in a color to differentiate it as not being editable in that view?
- Data view to display "Nickname" in a separate column from "element" (to save vertical space).
Hopefully these requests can make it in time to include in the next version – unless they're already in there...
and over in the A-D forum we find:
marksji
Quote:
Originally posted by chris.zeman:
I have a suggestion for the documentation editor in DirectSoft. There are many V-Memory locations reserved for use by the PLC, such as the clock/calender,
but they're not labeled as such in the documentation editor. It might be helpful if all reserved memory locations were already labeled.
Chris
I'll second that!
I'll third that!
-
Thanks for the feedback!
We're very hard at work in the final stages of our new controller project...MX. As such, almost everything we do in DirectSoft is currently focused on finalizing MX controller features. In some ways, new MX features will be answering your requests...although perhaps not in the way you've asked, because it is a significantly changed world from DirectLogic. Some of what you've asked for was already planned for a future release of MX. We're hoping to do a public preview here in the not too distant future, and would love everyone whose interested to download it, play with it, and tell us about it. We don't have a firm date, but it's looking like April right now. Stay tuned, you're gonna love it!!
For the Data View space thing, you might consider what we jokingly call 'Bob mode' here at Host (I'm the only one that uses it). Turn off your element display, and just leave your nicknames turned on. If there is not a nickname, we display the element. If you have a nickname, the element isn't quite so useful anyway (do I really care that is it C476?). We are planning a complete rewrite of Data View in a future MX release. Not sure yet whether it will be the 1.5 release or the 2.0, but it will be far more flexible than what is there now.
-
how about some h/w that actually is functional? I have 10 H0-Ecom-100's. Periodically they'll stop communicating to the D0-06 processors. They can still be pinged so its not network. Only way to restore communications is to cycle power.
I'll never use another Ecom for anything. I'm almost to the point of needing to rip out this crap and install something that works!!!!! So why don't you simply put a disclaimer in each box stating h/w and s/w is crap, will lockup randomly and can't be reset. At least then I could have returned this and saved myself a bunch of trouble. ???
-
how about some h/w that actually is functional? I have 10 H0-Ecom-100's. Periodically they'll stop communicating to the D0-06 processors. They can still be pinged so its not network. Only way to restore communications is to cycle power.
I'll never use another Ecom for anything. I'm almost to the point of needing to rip out this crap and install something that works!!!!! So why don't you simply put a disclaimer in each box stating h/w and s/w is crap, will lockup randomly and can't be reset. At least then I could have returned this <deleted> and saved myself a bunch of trouble. ???
So I guess that begs the question, did you come here for help, or did you come here to vent?
We have 10s of thousands of ECOMs and ECOM100s in the field. Judging by the amount of negative feedback I have gotten over the last 10 or 12 years...which I could count on one hand...they work very well for dang near everyone out there. Do we occasionally have bugs? Sure, and we fix them every time. Since the ECOM is still answering pings, it isn't locked up. It may be that the DL06 simply isn't talking to us any more; ECOMs are dependent on the PLC itself to process the request. On occasion, changes get made to the DL06 that cause option modules trouble. We've worked through every one to date, and we will work through this one if you will let us help.
It you are wanting help, I will have a technician contact you ASAP. If you want your money back, we are happy to refund it.
-
I admit I didn't read the entire thread, and that my experience with Host has only been on the ECOM100, but it has been a good experience.
My new features are security related, it feels as though a lot of these protocols in use by the industry are wide open:
IP or possibly MAC Address Filter for the ECOM100
Option to turn ModBusTCP listening off
-
I believe we got the OP taken care of, although I don't think we've heard back. Most have great success with our products.
We can look at security improvements for ECOM100.
I am very sure that you will like the upcoming MX-275E PLC that Host is developing. We put specific effort into improving security: 1) Our native protocol is session-based with configurable permissions by user, 2) Unsecured protocols like Modbus/TCP and KSequence can only access segregated memory, and 3) the Modbus/TCP server can be disabled.
-
Thanks for taking it into consideration!
See... I'm building a "Illudium Q-36 Explosive Space Modulator" ;D
And I don't want my centrifuges to get off kilter.
Have a great day!
BTW: what is this "upcoming MX-275E PLC"? I can't seem to find any documentation on it.
-
BTW: what is this "upcoming MX-275E PLC"? I can't seem to find any documentation on it.
Host has spent the last five years...give or take a bit...devloping a new control engine and programming package...MX and DirectSOFT/MX. It will be deployed first on new CPUs for 205...the MX-275 and MX-275E. We are just going to beta now with a planned fall release.
Because it is not officially announced, ADC will deny everything and probably wouldn't be thrilled at this posting. ;) So don't ask them.
Among a zllion other improvements, DirectSOFT/MX includes a full featured PC based MX simulator. We are hoping to do a 'Technology Preview' release on the Host forum some time in the next couple of weeks, which will allow you evaluate MX and DirectSOFT/MX by programming the simulator.
-
When time allows :D
...are you back up in your chair yet? To make it a full simulator, you'd probably have to upgrade it to work with configurable (a full rack of...) and remote I/O so you can actually simulate programs you write for actual projects. Eventually, I guess you'd have to do all the specialty modules as well.
-
Well...by 'full-featured' I was referring to the instruction set...not full process simulation. I think if we ever did a full process simulator we would make it a separate product and charge $$ for it.
That said, with Modbus/TCP client and server support, you could actually control a real process with the 'simulator'. The second major revision will include a native ERM function that will allow any EBC based IO to be used natively with MX.
Which is precisely why we are going to time-limit MX/SIM...not real keen on my simulator running somebody's plant.
-
Ooh, and what about taking the kernel of the simulator and making it into a working soft PLC for use with EBC, Koyo serial remote, and Modbus RTU and TCP distributed I/O?
I probably wouldn't use it personally, but I bet a lot of people would.
The Soft PLC, obviously, not being a part of the free simulator, if there ends up being a free simulator, but a standalone commercial product of its own.
-
Separated at birth, I see! ;D
-
We've actually talked about packing up the engine in DLL form and allowing people to integrate MX control into their application. Perhaps later.
As for a true PC control product...been around the block with that. Not opposed to it, but we'd like to begin recovering beaucoup million in R&D costs before we start muddying the stream.
Without a doubt, however, the retargetable MX engine can run control dang near anywhere. We'll let the market decide.
-
This is excellent news! I have been following the buzz for a while, and it looks like this new PLC and programming package will possibly deliver on many features that I've wanted, especially on board documentation and more user friendly math and data manipulation functions (i-boxes were a step in the right direction!). I will "patiently" wait for it's release!
I had been looking hard at the Productivity 3000, but definitely like the 250 platform. Hopefully the new controller will be compatible w/ the existing Hx-CTRIO cards or come w/ it's own hi speed counter cards.
-
This is excellent news! I have been following the buzz for a while, and it looks like this new PLC and programming package will possibly deliver on many features that I've wanted, especially on board documentation and more user friendly math and data manipulation functions (i-boxes were a step in the right direction!). I will "patiently" wait for it's release!
I had been looking hard at the Productivity 3000, but definitely like the 250 platform. Hopefully the new controller will be compatible w/ the existing Hx-CTRIO cards or come w/ it's own hi speed counter cards.
I am certain that you are going to be very pleasantly surprised. I-Boxes were great, but MX is a quantum leap over them. Fast, great math, very extensive instruction set, super comm, and a very nice bunch of native CTRIO instructions...and I am barely scratching the surface. We are also going to be releasing the CTRIO2 at the same time; MX has added some very nice motion extensions for the CTRIO2. It has been a very long development road, but we are very proud of the results. You're going to like this PLC.
-
Robert,
This is exciting news. I've always thought the DL205 platform had too much going for it to be obsoleted....glad you will be giving it a substantial upgrade in the form of a new CPU, new control engine and programming package.
Presently, I just love the CompactLogix with RSLogix5000 platfrom, but that comes at a cost. Really keen on seeing what you folks have in store for us.
Peter
-
Hi.
I have had one issue with Directsoft that continues to irritate me: When I type OUT and then try to enter a V-memory address, (forgetting to hit the forward-slash key) Directsoft just "bonks" and looks at me. Why can't the program "see" me type a "V" and automatically change to the correct function? >:(
I realize that this is a minor point, but the extra key-stokes during a lengthy programming session tends to irritate me as I usually type in the entire V-memory address THEN Directsoft protests when I hit the enter key. I now have to hit the forward-slash and re-enter the address. A waste of time.
Please humor me and at least see what it would take to include this in version 5.4.
-
Hi.
I have had one issue with Directsoft that continues to irritate me: When I type OUT and then try to enter a V-memory address, (forgetting to hit the forward-slash key) Directsoft just "bonks" and looks at me. Why can't the program "see" me type a "V" and automatically change to the correct function? >:(
I realize that this is a minor point, but the extra key-stokes during a lengthy programming session tends to irritate me as I usually type in the entire V-memory address THEN Directsoft protests when I hit the enter key. I now have to hit the forward-slash and re-enter the address. A waste of time.
Please humor me and at least see what it would take to include this in version 5.4.
Sadly, no.
Maybe we could make this an option in a future version. Would you also want a confirmation dialog (maybe you meant to enter OUT coil C7, but fat fingered and entered V7?). I'm guessing that if you have this feature ENabled, you would NOT want the confirmation?
-
I have had one issue with Directsoft that continues to irritate me: When I type OUT and then try to enter a V-memory address, (forgetting to hit the forward-slash key) Directsoft just "bonks" and looks at me. Why can't the program "see" me type a "V" and automatically change to the correct function? >:(
Just use the new MX processor and you'll probably never use another accursed OUT box! Hosties, does MX even have an OUT box?
-
Just use the new MX processor and you'll probably never use another accursed OUT box! Hosties, does MX even have an OUT box?
Nope, just OUT coil. No LD* instructions in the new MX controller either. No LD, LDA, LDIF, LDI, LDX, LDR, ... None, nada.
The accumulator is not directly accessible via user instructions, so MATH gets easy
(SQRT(R1 + V0) / 3.14 + D7) * LOG(V1)
where R1 is an IEEE 32 bit floating point register
V0,V1 are 16 bit unsigned integer registers (range of 0-65535)
D7 is a 32 bit signed integer register (range of +/- 2 Billion)
-
Yeah, I was thinking between MOVE and MATH, why would you ever need an OUT box anymore?, but wasn't sure if you kept one for old school guys. Personally, I'm glad to be rid of the thing. Working on the 405 when I was used to the 505 made me want to pull my hair out, between the accumulator, octal, and BCD, especially BCD. Oh, and no K-Memory and no forces (at that time).
-
Since the math stack is now managed by MX, and must stay at a well defined state, it was necessary that all instructions that modified the stack be private instructions. There are several different ways you can go about getting a value into a register in MX...MOVE, INIT, and MATH...and perhaps 5 others I am not remembering.
-
Oh, believe me, I'm not lamenting its passage. More like dancing on its grave.
-
I know a while back in this thread we spent some time on PID's... I have had an issue on a couple of applications where it would really help if the error deadband could be adjusted to offset the split between the positive errors and the negative errors. For example: I have been working with some processes that are constantly pushed to the "red line" and the operators want really tight control of the top end of their process. they don't care if the loop is a little slow to come back up if it gets a little low, but expect a fast response to bring the process back down. The problem is, the process responds very quickly to an increase in output, but really lagges in response to a decrease in output. It would be really nice to be able to enter two separate error deadbands for positive and negative errors to greatly simplify the program. I know that rll can control this using compares and the read-on-the-fly deadband term,(Or maybe even run two completely separate algorithms for positive errors and negative errors) but maybe this is something that can be easily changed when you all dig into ds5 again... (I haven't had a chance to check out mx to see how it deals with this situation). Thanks for your time
Any advice from you experienced process engineers in cyberland is always appreciated (sometimes I just look at things backwards :-\)
-
I'm new to the forum and didn't have time to read all 15 pages of posts so I apologize if I have repeated someone else's request. Do you have any modules designed to interrogate card readers used in access control projects. We install a lot of HID card readers using Wiegand Protocol and it would be extremely beneficial to integrate the Access Controls with the other Building Controls we do.
-
I'm new to the forum and didn't have time to read all 15 pages of posts so I apologize if I have repeated someone else's request. Do you have any modules designed to interrogate card readers used in access control projects. We install a lot of HID card readers using Wiegand Protocol and it would be extremely beneficial to integrate the Access Controls with the other Building Controls we do.
There isn't a "Wiegand protocol" built in (unless it's just Modbus and they've stuck a proprietary name on it or something), but the new platform has features that make creation of custom protocols very easy, for use via either serial or Ethernet. I think BobO was saying that a guy at Automation Direct hacked out a DF1 (Allen-Bradley) implementation in two hours or something like that, so what you'd have to do would be to build the protocol yourself.
-
As the Wiegand system uses a different hardware wire setup and a non-byte based communication packet it may be a little difficult to implement but good luck. http://en.wikipedia.org/wiki/Wiegand_interface (http://en.wikipedia.org/wiki/Wiegand_interface) There are Wiegand -> RS232 hardware and protocol convertors available.
-
I had never heard of it, but Google is your friend. ;)
The hardware interface is obviously custom, but could easily be done. The protocol sounds trivial. I guess the big issue is that after 20 years of doing this, this is the first request for it...probably due to the fact that PLCs are rarely used for building access/security. If there were a market for it, I'm sure it would be very simple to do it...just not sure there is enough of a market to cover the development cost.
-
I just found this topic, so I hope someone is still monitoring.
My biggest wish that I scan every new PLC for, and so far have failed to find (with the exception of the heavy lifting NI Compact-RIO) is an event timer card. It would have the following capabilities.
1. Allow the PLC to adhoc access a fast clock, say 16 or 32 bit running at 1uSec per count.
2. Log the precise time of input events (separately log rising and falling edges) using that clock. Interrupts would be optional.
3. Allow Output channels to turn on and off at precise times, again based on the 1uSec clock. Interrupts would be optional.
This opens up all sorts of application options that are currently poorly met by such as the CTRIO card.
OH OH, I forgot something...
Since Modbus is always going to be the lowest common denominator for data access, it would be nice if the Ethernet interface incorporated a little security, such as restricting write access to a settable range.
-
My biggest wish that I scan every new PLC for, and so far have failed to find (with the exception of the heavy lifting NI Compact-RIO) is an event timer card. It would have the following capabilities.
1. Allow the PLC to adhoc access a fast clock, say 16 or 32 bit running at 1uSec per count.
2. Log the precise time of input events (separately log rising and falling edges) using that clock. Interrupts would be optional.
3. Allow Output channels to turn on and off at precise times, again based on the 1uSec clock. Interrupts would be optional.
We have actually been considering similar functionality in some yet-to-be-developed hardware.
Since Modbus is always going to be the lowest common denominator for data access, it would be nice if the Ethernet interface incorporated a little security, such as restricting write access to a settable range.
Do-more actually does this, at least partially. Modbus access is already limited to Modbus specific memories, although we do not currently allow limiting writes to a subset of that. Doesn't seem like it would be particularly difficult to do, and would definitely enhance the security further.
-
I have something simple to add!
In 'Data View' and 'Change Value', It would be great to have a toggle button and a momentary button.
The toggle button would turn OFF what is ON and turn ON what is OFF.
The momentary button would turn ON momentarily what is OFF while the button is presses and OFF momentarily if it is ON.
The ON OFF buttons are OK, but when you want to emulate a Push-Button you have to first turn it on then turn it off.
-
Well, I have been using the Do-more on a couple of jobs now and I really like it. Definitely a few quirks yet, but very, very powerful and super fast. Unfortunately, I have found that not all vendor's ethernet comms are up to snuff speed-wise, so I am still stuck using analog on them. This is not Do-more's problem though because it is able to service another vendor's product at the same time at a very respectable speed.
I am hitting all of the slow devices about 4-5 times a second (write a change, internally linked, read the change back). The quick one at least 10 times faster. The slow devices were about 3 seconds per device sequentially! on a D2-260 with Ecom-100! I was still disappointed, but it wasn't Do-more bottle-necking me. I almost forgot to mention how easy it was to set up the comms for 7 Modbus/TCP devices!
Now for the requests:
I would also really like to have LWgreys' request for the toggle and momentary buttons.
I would love to have a RAMP instruction or RATE LIMITER maybe, but RAMP (as in accel, decel with S-ramp ideally) for use in drive control systems. I can build my own (INTEGRAT!), but we don't quite have the user structures yet that would make that painless. BTW, that S-Ramp has to be "on-the-fly" as opposed to a positioner type as the input could be changed at any time.
Yes I would love to have Add On Instruction ability, and User Data Types (say Drive_2.AccelTime etc.) And not being able to have a User Memory type with a number in the name is a drag (Drive2).
If Then Else in the MATH instruction is cool! But it's kind of hard to read after it's built so I dropped my one use of it in favor of MATH + CLAMP (another cool instruction along with LERP)
I would like to love the Nicknames, but I am having access consistency issues. Like in a MATH instruction I don't seem to have an Auto Complete or pickbox at which point I was better off with R20 instead.
And one last nit to pick (for now ;)) when will we ever see our software installed under Program Files\AutomationDirect ? I am none too keen on software installing into C:\ though Host is not the only one to do it.
Seriously, I love these products (mostly)!
-
When I click in a MATH box, I get a list. Not sure if it's just symbolic constants or if it also has nicknames.
As far as directories, look for a utility called COA (Change Of Address). It will move installed apps, and go fix all the registry entries and shortcuts and so on to point to the new directory.
I was usually using it the other direction (to get stuff OUT of Program Files and into a logical hierarchy).
-
Well blow me down! I've loaded DMD at home (less stress don't you know) and discovered two new things.
1) The Previous, Next and Output Cross Reference search buttons! (Don't press that button, you may blow up the world!) are fabulous. I was having issues with the Cross Reference View when following the cursor doing weird things, but those buttons work great.
2) That useless, annoying, Element Browser that was always popping up unwanted, works alright once you untick the "Filter on Selected Range" box (each and everytime so far, maybe I can find how that turns off too.) Now I can find the nicknames. Better and better. Thanks Controls Guy!
-
I would love to have a RAMP instruction or RATE LIMITER maybe, but RAMP (as in accel, decel with S-ramp ideally) for use in drive control systems. I can build my own (INTEGRAT!), but we don't quite have the user structures yet that would make that painless. BTW, that S-Ramp has to be "on-the-fly" as opposed to a positioner type as the input could be changed at any time.
RAMPSOAK isn't S-Curve, but can you not build a ramp profile with it?
Yes I would love to have Add On Instruction ability, and User Data Types (say Drive_2.AccelTime etc.) And not being able to have a User Memory type with a number in the name is a drag (Drive2).
User data types and functions are coming in DmD 2.0.
Because we don't use a token to delineate normal array type memories (X0 vs X[0]) it becomes very difficult to parse if you allow numbers in block names. If I have MyBlock2 and MyBlock22, what does MyBlock221 reference? As much as we would like to support it, sanity must prevail. I would say that user data types will help to a significant extant.
I would like to love the Nicknames, but I am having access consistency issues. Like in a MATH instruction I don't seem to have an Auto Complete or pickbox at which point I was better off with R20 instead.
It's something we want to address.
And one last nit to pick (for now ;)) when will we ever see our software installed under Program Files\AutomationDirect ? I am none too keen on software installing into C:\ though Host is not the only one to do it.
The issue is that we run into many painful side effects of Microsoft's ever-changing security-of-the-week. Writing to the various files that store states (options, comm links, etc) become problematic. They could be (must be) written elsewhere, but that tends to create support issues. We're not opposed, but there are a dozen issues that have to be addressed...and there are many other higher development priorities.
-
RAMPSOAK isn't S-Curve, but can you not build a ramp profile with it?
Well I tried it, but I don't think it is what I am looking for. The simulator is pretty fun at home though and I have the beginnings of an S-Ramp kludged up (I am not even trying to do the fancy math a true S-Ramp seems to use.) It is trending pretty decently. Now I need to clean it up so it looks like a digital drive's S-Ramp.
I am looking forward to DMD 2.0!
-
Just do a parabola or a sine function. I think that's what all the commercial implementations are doing. A constant third derivative (jerk) will produce a parabola on the velocity plot.
-
Accel/decel is a trapezoid.
-
Accel/decel is a trapezoid.
Only in the simplest case.:( An elevator is a good example of why you want an S-Curve and want it well tuned. Too little S and it is harsh, too much and you are wondering if you are ever going to get there.
Controls Guy has it right as far as Jerk, but it is actually pretty complicated to get a good curve and a real time change to speed setpoint completely hoses the look-up tables as best I can tell.
http://www.pmdcorp.com/news/articles/html/Mathematics_of_Motion_Control_Profiles.cfm (http://www.pmdcorp.com/news/articles/html/Mathematics_of_Motion_Control_Profiles.cfm) has an article about it but it is aimed more at position profiles where you already know precisely where you are going.
My applications are much more like driving a car. You don't just push the pedal for how fast you want to be going, you feather it at start and at up-to-speed. You do the brakes the same way. (Yeah I know, some people just hammer both.) And the situation is constantly changing so you may need to slow back down before ever arriving at your earlier setpoint and you want the same smooth-rate acceleration changes.
Anyway, it is one of those "all you gotta do" type problems I just hate to be assigned...
-
Accel/decel is a trapezoid.
If you're saying that a plot of the accel during the accel (or decel) ramp is a trapezoid for an S-curve profile, yes, for certain cases that's true (the ones with a straight section of accel/decel with only the corners rounded). Sometimes though, the S sections actually meet in the middle. For that case the accel plot wouldn't have a horizontal segment, it's always increasing or decreasing according to some function (which function could be as simple as linear). In the linear case, the plot will look like a triangle.
Since the integral of mx+b is 1/2(mx^2) + bx, then the velocity profile will have an s-curve made from two parabolic segments. The jerk profile will look like a bipolar square wave (positive then negative, or positive, zero, negative depending if there's a constant accel segment in the middle).
-
it is actually pretty complicated to get a good curve and a real time change to speed setpoint completely hoses the look-up tables as best I can tell.
The math shouldn't be that bad. It's just going to end up being a quadratic you can derive pretty easily if you know your new velocity target and how long you have to get there. The iffy part is that you'll have to do it in ladder and the ways you have to get the data out to the drive (write new velocity setpoint to a CTRIO, or use an analog output), may be too low bandwidth to give you the performance you want.
-
If you're saying that a plot of the accel during the accel (or decel) ramp is a trapezoid for an S-curve profile, yes, for certain cases that's true (the ones with a straight section of accel/decel with only the corners rounded). Sometimes though, the S sections actually meet in the middle. For that case the accel plot wouldn't have a horizontal segment, it's always increasing or decreasing according to some function (which function could be as simple as linear). In the linear case, the plot will look like a triangle.
Since the integral of mx+b is 1/2(mx^2) + bx, then the velocity profile will have an s-curve made from two parabolic segments. The jerk profile will look like a bipolar square wave (positive then negative, or positive, zero, negative depending if there's a constant accel segment in the middle).
The triangle case is just a special case of the more generalized trapezoidal accel/decel. My point was simply that S-curves aren't really that mathematically complicated. The hard part is in developing the math to predict the correct values for the accel/decel profile to hit the exact target point at 0 velocity. For a basic trapezoid it's easy. S-curve not so easy and I'm guessing brute force may be the preferred solution. Only problem is whether you have enough CPU to crunch the numbers fast enough.
-
Every time I think we're on the same page you lose me! Are you talking about trapezoidal a/t plots or trapezoidal v/t plots?
Edit: OK, if I got my napkin scribbling right, the equation V = f(t) to decel from initial velocity V0 in distance d with full parabolic S-curve (no constant-a section) is:
Vt = v0 - (v03/2d2)t2
...and everything on the right side is constant except for t, so it simplifies to
Vt = v0 - kt2, where k can be precalculated once for the entire ramp.
If I get a chance I'll try to confirm that tonight or tomorrow; it checks out dimensionally at least. That's for the first half of the S-curve (negative accel, negative jerk). For the second half (negative accel, positive jerk), you could either do the math again or just build a table while you're doing the first half and crawl it backwards.
So IMO the math isn't demanding CPU-wise, I think the bottleneck is going to be CPU-CTRIO comms or the analog.
-
Nothing hard. Just saying that an S-curve velocity is produced by a linear accel, and the linear accel can be either triangle or trapezoidal...triangle being a subset of trapezoidal.
The velocity math is easy. The brute force part is determining the required change in position to decel to a specific velocity...in most cases 0, but for blended moves the velocity may not be zero. So for a given position, velocity, and accel, how many pulses y will it take to get to velocity=x?
-
Nothing hard. Just saying that an S-curve velocity is produced by a linear accel, and the linear accel can be either triangle or trapezoidal...triangle being a subset of trapezoidal.
OK, you spelled it out well enough even for me! :D That was the same point I was trying to make. Also, linear A does produce an S-curve move, but it doesn't have to be linear. Any function whose integral is a curve and has horizontal tangents would work. Sin/cos for example, or A could be quadratic and make V a cubic, which would still yield an S-curve. Most apps I'm sure won't justify the extra effort, but it's there if for whatever reason we need it some time.
The velocity math is easy. The brute force part is determining the required change in position to decel to a specific velocity...in most cases 0, but for blended moves the velocity may not be zero. So for a given position, velocity, and accel, how many pulses y will it take to get to velocity=x?
I don't think it will be a whole lot worse. Bit of a different situation -- in a decel ramp, the final velocity and position are critical and time will become the wagged tail. In a ramp to a non-zero V, the final V is obviously important, but time might overshadow the position at which the ramp terminates.
-
Ideally you'd love to be able to enter current position, current velocity, current accel, and target velocity into a formula and have it spit out resulting position. That's pretty easy to manage with fixed accel/decel, but my guess is that it isn't quite so easy for S-curve and will require either PHD math (and I ain't that smart) or simple math iteratively (processor must be fast enough).
Gotta figure out when to start stopping the train to perfectly hit the station without the passengers spilling their champagne...even while we were still accelerating from the previous stop.
-
Very doable (and I ain't no PHD either)!
In addition to the initial conditions you list, you'd need to input maximum achievable values for velocity and accel (a really thorough model would have separate accel and decels to account for limits due to overhauling loads) as well as max jerk (which is more a design constraint than a physical barrier).
I'll check my inventory of napkins and get back to you. ;D
-
I'm all for doable. Franj is actually a math major from an elite nerd school. Me, not so much.
-
If I can't count it on my fingers, I'm outta luck. Fortunately, I got calcoolus fingers.*
*"Stand and Deliver" reference. Stand and Deliver is the classic nerd movie. Like Star Wars, but for nerds.
-
Well as for my needs and the reason for the request, I am needing "simple" velocity control, not positioning. I need to ramp a machine up and down in speed with multiple drives and motors typically. The need for the "S" has more to do with tension control in a web. Position needs are usually (although not always) much more basic or even non-existant. More demanding is the need for an operator to be able to crank the line speed pot wherever he/she wants at any time and have smooth control. Overshoot is probably just fine to prevent transients due to a setpoint change, but should not be unreasonable.
Research over the past weekend was indicating multiple equations needed at various times and probably the foggiest part for me is predicting when to transition from one to another without transients being introduced.
I am looking at total ramp times from 10-120 seconds, not pick and place speeds at all.
-
I was going to ask for MATH IF THEN ELSE nesting that allowed for comparisons that were equations along with results that were equations because I could not get that to work a couple of days ago. But I just tried it again and it works very, very fine.
So instead, I would like to humbly request that MATH IFs get some type of nice formatting so I can figure out just what I am trying to do. I really like not having to have scratch values as required with comparison instructions (which won't take equations, hint, hint.) along with the multiple rungs needed, but without some kind of clean formatting it seems like a bad idea for me to get into that kind of complexity.
This is what I tried (Bogus Stuff)
MATH
Result R0
IF((R1 + R2) > (R3 + 3.0), IF((R4 + 1.0) <
(R5 + 5.0), 1.0 + R3, 0.89), 2.0 + R6)
It works, but is kind of hard to follow, especially with nicknames or PID_Control1.Output added in liberally and broken up randomly. Maybe different colors or true IF THEN ELSE or something.
Or MAYBE I am looking for a decision tree instruction! Hang it off the left rail and branch off from the results to the right. Wait, this sounds like a flow chart, huh, maybe not.
But I would love Function Block Diagrams for analog type stuff.
-
I was looking at this exact issue over the last couple days (legibility and troubleshooting with MATH box expressions), and I came to similar conclusions.
I'd like to see some live status within the expression, and also the ability to format it a little, at least when the box is open for editing. Let us put in carriage returns for instance, and retain them, at least when editing the box.
AB on the CLX has a pretty good what I'd consider a partial solution to showing status in CPT (MATH) boxes; if you hover over a variable, the value pops up in a tooltip.
And yes, CMP complex compares are a feature I LOVE in CLX and use often. Very much more powerful than previous AB generations that had only simple compares such as EQU, NEQ, GRT and so on.
(Hosties, in this feature you can write a complex comparison like SQRT(R100) + D500 / 3 > 5, and place it midline in a rung like a normal compare. It's not an output box like CMPD in DL-classic)
-
The engine already supports expressions for virtually any input, and already has an expression contact. The hard part is handling the display and editing. The issues with the MATH box...no auto-complete, for instance...are the types of things we need to resolve before we add expressions throughout.
-
Really looking forward to the expressions-everywhere thing. That's going to be extremely cool (and unique in the field)! :)
-
First of all I don't think I've ever thanked you guys for adding the Delta contact. You can use it in all sorts of ways. ;D
One place I chose not to was one of those cases where you want to do something on the stroke of midnight (clear some daily total registers in my case). You could use an equal comparison of $Now.Hour with 0, but then you must use an inline one-shot or add minute and possibly second compares so it doesn't hold the totals to zero till 1am, and besides, with this equipment some users may not let it run 24/7. If it's off at midnight, I still want the totals to get cleared on power up.
What I ended up doing was remembering the last day on which the totals were cleared, and do a not-equal compare of $Now.Day with that. If not equal, clear the totals registers and set the date memory register. This works both at midnight and on power up on a new date.
So this brings be back to the delta contact. I could have simplified the ladder if I could have started the ladder with a simple delta contact of $Now.Day, which works great at midnight but not on power-up (apparently the last-scan state isn't retentive). So that starts me thinking about how the delta contact SHOULD work. In this case it would be better if last state were retentive, and it could potentially go true on first scan, but I could also come up with some cases where you wouldn't want that.
I concluded that it would be more flexible if it were the other way, because we could turn it back into this version with NC ST0 if needed, but there's no way to turn this version into the other. Any thoughts?
-
Edge retention is tricky. Not hard, just difficult to predict how people really want to use it. Ditto for startup states in general. Do you assume a clean start, or do you attempt to resume. A perfect resume is hard, so you generally wind up with startups that are "only mostly dead". Sorry...poor movie humor.
In this case I would probably resort to a relational != on $Now.Day to edge trigger the DoMyDailyThing task or program, which would update the retentive DayLastDone variable. Not as simple as a delta, but pretty easy and reasonably robust.
-
Right, that's what I ended up with, and I agree it is relatively clean. It just started me thinking about the details of the delta so I posted about it. This is the first time first scan behavior has even been an issue using that instruction, so it's evidently somewhat of an edge case.
-
I have had the identical issue as Controls Guy: when someone shuts the power off to the system overnight, then it never performs the reset.
One option is to MOVE $Now.Date to d_DateOfShutdown in $tLastScan,
and then $NOW.Date != d_dDateOfShutdown---------PerformWorkHere in $tFirstScan.
-
Here's what felt the cleanest to me:
STRNE $Now.Day V100
MEMCLEAR MHR40 10
MOVE $Now.Day V100
That covers both midnight and power up on a new day cases.
-
Here's an example of a case where I'd like some formatting in MATH box expressions:
((Drum[V0] | IF(MHR7:0 & C201, RelayWDCfg0:SD, 0)) & IF(C103, -1, RelayPanicCfg0:SD) &
IF(ST4, ~RelayFlashCfg0:SD, -1) & ~RelayTypeTOD0:SD) | (RelayTypeTOD0:SD & TODOutputs0:SD)
Actually doesn't look too bad on screen but hard to follow scrunched up in a little MATH edit box or at runtime.
-
Few more feature requests:
(1a) Optional and adjustable fuzz factor for matching in COUNTIFEQ.
(1b) New COUNTIFLIM function that allows specification of upper and lower limit and returns the count of values falling between.
As you can see, (1a) and (1b) are somewhat interchangeable, but they excel in slightly different cases, so consider this a strong request for one or the other and a mild request for both.
(2) A SEARCHR or FINDR function that finds a value (presumably with selectable fuzz match factor), and returns the INDEX of the value in the table rather than the VALUE. Could be used not just for finding foreknown values, but also for example finding the index of the MIN by doing FINDR(MINR()).
(3) BCD conversion functions that can be used in a MATH box.
-
Have a new idea. I was looking at one of my old C++ programs and thought "It would be something if there was a PLC that used C++ syntax for the programing". Just think of the power the programmer would have! Yes I do C++, PASCAL, BASIC and the dreaded Assembly language also.
-
I think plans are to eventually support Structured Text, which in most platforms comes out kinda like a PLC-itized version of BASIC. (Also a cleaner more industry-standard implementation of SFC than Stage).
-
Feature request: My original request was going to be to allow indexed variables in a Data View (MyArray[V100] for example), which I would like. Then that of course suggests the more general solution, which would be to allow expressions in general in a Data View.
-
Feature request: My original request was going to be to allow indexed variables in a Data View (MyArray[V100] for example), which I would like.
That's already in there.
Then that of course suggests the more general solution, which would be to allow expressions in general in a Data View.
That may take a while.
-
It is? I thought I tried it today and DMD wouldn't allow it. Have to check again tomorrow.
-
It is? I thought I tried it today and DMD wouldn't allow it. Have to check again tomorrow.
Rel 1.3 even supports offset arrays in Data View/Ladder status, e.g. R[V0+2]. See the attached screen shot.
-
Very good to know - thank you!
Update: Have been happily using indexed arrays in Data Views since I learned about the capability in this thread. Very, very cool! Manual? What is this "manual" you speak of? :D
-
Feature idea (haven't given this adequate thought to really call it a "request"):
Each code-block has some yielding configuration, from never yield, to always yield, to time-slice. It occurs to me that it would be helpful to be able to delineate a "no-yield zone" in the code, within which the program/task will not yield based on instruction type or time interval (concept obviously doesn't apply to code-blocks configured to never yield). So new NOYIELD and NOYIELDE left rail instructions or something.
-
Feature request: functionally defined breakpoint in Debug mode. IOW the breakpoint is "When N0 is changed to -1", and the last line executed is recorded.
-
Feature idea (haven't given this adequate thought to really call it a "request"):
Each code-block has some yielding configuration, from never yield, to always yield, to time-slice. It occurs to me that it would be helpful to be able to delineate a "no-yield zone" in the code, within which the program/task will not yield based on instruction type or time interval (concept obviously doesn't apply to code-blocks configured to never yield). So new NOYIELD and NOYIELDE left rail instructions or something.
You kind of don't need it, but can really already do it. First, the only instructions that actually yield are looping/goto that go backward...the time slice is only evaluated by 4 or 5 instructions. Second, you can change the .Timeslice member any time you want. So if you did have a loop that needed to not yield, it is a simple matter of setting the time slice to 65535 and restoring it at the end of the loop. It might be nice for documentation purposes to have an instruction like you described, but the implementation would be exactly what I described.
-
Feature request: functionally defined breakpoint in Debug mode. IOW the breakpoint is "When N0 is changed to -1", and the last line executed is recorded.
As long as it was a simple data compare, that wouldn't be that hard.
-
You kind of don't need it, but can really already do it. First, the only instructions that actually yield are looping/goto that go backward...the time slice is only evaluated by 4 or 5 instructions. Second, you can change the .Timeslice member any time you want. So if you did have a loop that needed to not yield, it is a simple matter of setting the time slice to 65535 and restoring it at the end of the loop. It might be nice for documentation purposes to have an instruction like you described, but the implementation would be exactly what I described.
Oh yeah, I forgot you could dynamically write to .TimeSlice members from ladder. Perfect. What I was thinking was that there might be some operations you wanted to protect, and having rung-level definition of non-yielding zones lets you loosen up the config for the code-block as a whole rather than having to make the whole thing no-yield. Perfect solution. Thanks!
-
Feature request: a conditional (right rail) version of YIELD. Or can I already do that similarly to the previous case by manipulating .TimeSlice?
-
Feature request: a conditional (right rail) version of YIELD. Or can I already do that similarly to the previous case by manipulating .TimeSlice?
YIELD instruction is unconditional, and it ALWAYS yields, regardless of .TimeSlice. Not sure of a better way to do a CONDITIONAL YIELD. It would need to be a new instruction YIELDC.
-
Right. I was thinking not in terms of having a YIELD but of making .TimeSlice small and them doing something that would trigger a yield. Or maybe using a conditional backwards GOTO or something (making sure to clear the jump condition). Nevertheless, a YIELDC would be cleaner, so give some thought to whether you think it would be worthwhile.
-
Right. I was thinking not in terms of having a YIELD but of making .TimeSlice small and them doing something that would trigger a yield. Or maybe using a conditional backwards GOTO or something (making sure to clear the jump condition). Nevertheless, a YIELDC would be cleaner, so give some thought to whether you think it would be worthwhile.
Those would work.
-
Being as we don't actually use PLCs for a living, we've been known to miss a thing or two. If there is a good application reason to add it, we are happy to do so.
-
For me, it essentially comes down to the same issue that led to the previous post -- having fine grained control over where exactly in the ladder a given code block may yield. One example case for this latest request would be within a loop. Let's say I don't want to complete all the loop iterations without yielding. I can't configure to Yield-at-every-yielding-instruction, nor put a explicit YIELD within the loop because then it will yield every iteration, which may be too much.
I may not want to use timed yielding because then the yield will occur at an unpredictable point in the loop logic. So say if I want to yield after every 10 or hundred iterations, but only at the end of the loop, there's no clean way to do that now.
All three of the current options are quite valid and will see many cases in which they're perfect, but there are some odd cases where none of the three is exactly right, and a YIELDC would allow the user to precisely define yielding conditions.
I ran into a case where one program would push a number into a queue and another was scanning the queue for matching numbers and if it found one, it would act on it and clear that queue position. The acting program would sometimes clear the queue slot prematurely when the packing program had barely had time to enter it, and then it was missing when really needed, and I couldn't seem to get it to interlock using MyOtherProgram.Running and so on. I inserted my own flags for comms between the two and that seemed to take care of it, but it got me thinking along this line of fine-grained execution control and coordination.
-
One way to do that now would be two nest two loops with the inside one iterating n times between yields, and the outer loop yielding on every iteration. Less clean in general, plus making the index math more complex in the inside loop. You see my point.
-
A conditional YIELD would be wonderful. Very handy for troubleshooting as well.
-
Feature request: Indexable bit-of-word, as in MHR[V101+1]:[V102+2]. Might not ever need the fixed "+2" offset in the bit index, but included it for consistency with normal DM indexing.
Example: I'm setting or clearing a single bit in a register addressed indirectly, so
MATH Mask (1<<RelayIdx)
MATH Drum[DrumIdx] Drum[DrumIdx] | Mask
to set, or
MATH Mask ~(1<<RelayIdx)
MATH Drum[DrumIdx] Drum[DrumIdx] & Mask
to clear. This would be cleaner if in one rung I could unconditionally do:
MATH Drum[DrumIdx]:[RelayIdx] SetClearFlag
-
Feature request: Indexable bit-of-word, as in MHR[V101+1]:[V102+2]. Might not ever need the fixed "+2" offset in the bit index, but included it for consistency with normal DM indexing.
Just stick your mask into bit memory, and use CASTS for DWORD reference, otherwise you have complete control of bit level and mask level indirection.
Since you need to also look at your bits as DWORDs, you will need to start your mask on a 32-bit boundary, e.g. C0 or C32, etc.
When indexing the MASK as a DWORD, make sure your index is on a 32 bit boundary, e.g. V0 = 0, 32, 64, etc.:
C[V0]:SD
When indexing the MASK as a BIT, well, it's just the native bit offset:
C[V0]
Basically, whenever you need indirect addressing, make sure you make your base data-block's native data type be the resolution of your indirect addressing needs. You can always use casts to look at the higher level resolution at a lower numeric resolution, making sure you start the array on BYTE, WORD or DWORD boundary.
Bits and DWORDS/REALs: Start on 0, 32, 64, 96, etc.
Bits and WORD: Start on 0, 16, 32, 48, etc.
Bits and BYTE: Start on 0, 8, 16, 24, etc.
BYTEs and DWORD/REAL: Start on 0, 4, 8, 12, etc.
BYTES and WORD: Start on 0, 2, 4, 6
WORDs and DWORD/REAL: Start on 0, 2, 4, 6, 8
-
Right, I was aware of all of that, and if you use a native bit type, then you can index either the bit position OR the register location indirectly, but not both at the same time in the same expression. One or the other must be literal. What I can do with what you listed is roughly equivalent to the "before" version in my original post, unless I'm missing something.
-
IOW what I'm saying is that I have a register which already must be addressed indirectly (Drum[DrumIdx]). I want to address a bit indirectly within that register, and I don't believe there is any way to do so any more explicitly than what I posted. Is that incorrect?
In other words, the mask word is only necessary at all because I can't simultaneously indirectly address a register and a bit within it. (Plus the duplicate rungs decision whether to use OR or AND would go away too).
-
IOW what I'm saying is that I have a register which already must be addressed indirectly (Drum[DrumIdx]). I want to address a bit indirectly within that register, and I don't believe there is any way to do so any more explicitly than what I posted. Is that incorrect?
In other words, the mask word is only necessary at all because I can't simultaneously indirectly address a register and a bit within it. (Plus the duplicate rungs decision whether to use OR or AND would go away too).
You are correct. You cannot do two levels of indirection, i.e. an indirect cast and indirect block/array index. Indirect casting, e.g. varying the bit cast or varying a byte cast or varying a word cast at runtime, is not supported. But you CAN do what you are trying to do by just using a base block data type of bits, and then you CAN do what you are trying to do, indirectly access a DWORD and a BIT whenever you want (not just in logic, but also in a Data View or Ladder View!).
Just use a bit block, and you CAN get the same result as indirect cast AND indirect block/array index.
-
Since it still by definition has to be at least as many separate steps as the current method, I'll call that a wash. May consider using it on a new project before it's so committed to this method.
That was an idea I hadn't thought of, thanks!
Anyway, the bit-of-word indirection post started out as a feature request, and so it shall remain! :)
-
1) I mentioned this elsewhere in passing, but I would like to see if it is doable as a feature request. In Rockwell stuff, where a colon is required, the software allows you to type a semicolon instead and it converts it for you to a colon. I would really like to see this in the Do-more Designer also as shifting to get to the colon is really a pain. (I know C programmers get to do it all the time - it is why I preferred BASIC (I don't speak punctuation very well.))
2) An issue I was noticing relating to starting a new rung with a normally open contact by simply typing the address was giving me issues today. When typing HR50:1, DmD was omitting the R. It only seems to happen at the start of a rung if the instruction type is not selected first. I had the same problem with IR113:1 - again R, but not as often. It could be my computer is old and slow. The program was over 200 rungs when this started giving me issues. Cut and paste was really slow at that point too. It seemed that it was ignoring the keyboard buffer while it inserted the NO contact. Win XP on Pentium 4 2.4 GHz 1 GB RAM, piddly old AGP video card. It only does it when I'm not watching for it (how do they do that?)
-
Not sure how I feel about the semicolon conversion...not because I am opposed to helping those who are punctuationally challenged...but because by converting, you are essentially giving up the possibility of ever using the semicolon for an operator. It actually would be pretty simple.
I suspect that the dropped character is a slow PC thing. We start the edit operation on the first character...which is forwarded to the editor. All subsequent characters go to the editor window itself. If that takes more time than your character spacing, I could easily see it getting dropped. I realize it may not be the answer you wanted to hear, but we made a conscious decision to develop DmD for more modern PCs, choosing to do some things to make it better, knowing that it may not run well on older machines.
-
Not sure how I feel about the semicolon conversion...not because I am opposed to helping those who are punctuationally challenged...but because by converting, you are essentially giving up the possibility of ever using the semicolon for an operator. It actually would be pretty simple.
Nah, you wouldn't want to do that, it's too hard to tell them apart. My stupid "smart" phone has a semicolon on the keyboard, but you have to go to a menu to get the colon - DUH, nobody would need a colon for time or anything I reckon. But now that semicolon... what good is that thing anyway? I never could figure out when to use it.
I suspect that the dropped character is a slow PC thing. We start the edit operation on the first character...which is forwarded to the editor. All subsequent characters go to the editor window itself. If that takes more time than your character spacing, I could easily see it getting dropped. I realize it may not be the answer you wanted to hear, but we made a conscious decision to develop DmD for more modern PCs, choosing to do some things to make it better, knowing that it may not run well on older machines.
Yeah, but I'm attached you know? I am going to have to break down and get a wide screen monitor though.
-
Yeah, but I'm attached you know? I am going to have to break down and get a wide screen monitor though.
Come on...I give you free software. Take the $400 I saved you and drop it on a state-of-the-art three-year-old clearance PC. It'll be 20x faster and come loaded with a plethora of useless bloat-ware. Bonus! ;)
-
All true, but this is my home computer (and upgrades here come out of my pocket. :)
The work machine is a bit faster. And has the big monitor. And distractions I don't have at home. ;D
-
But now that semicolon... what good is that thing anyway? I never could figure out when to use it.
When you write a sentence containing two or more clauses, separate them with semi-colons. (A clause is a phrase containing a subject and predicate. It could stand on its own as a sentence, but sometimes you want to put two closely related thoughts together in the same sentence.)
So: We had to hike to the gas station; our car ran out of gas.
-
New feature request:
Could we have the ability to access the raw bytes of a string?
Example:
MATH
Result: SS2:B[V2}
Expression: SS12:B4+D16
Or
MATH
Result: SS[V1]:B[V2}
Expression: SS2:B4+12
Or
Comparative contact:
SL3:B2 >= 12
Maybe their is more to it than I realize, but it seems this data is already there, I am just not allowed to reach out and get it.
I realize that I can use STRGETB, but then I have a stack of instructions to do one simple job...
-
Very hard, for reasons I won't bore you with...but...we could easily add MATH box functions to crack/cast strings that could do the things you are wanting, at least on the right side of the equation. Unfortunately the left side is a very hard thing...
-
That will be a big help. STRPUTB should be sufficient to finish the job.
Thanks!
-
It would be nice if open programs/tasks could be set to auto-sort left-to-right, in order of execution, similar to the Project Browser.
-
It would be nice if open programs/tasks could be set to auto-sort left-to-right, in order of execution, similar to the Project Browser.
Nice idea. We'll put it in our "potential feature" database!
-
1. Search and replace function for strings, with multiple matches/replacements per string. Wildcards in the search string would be nice too.
2. More complex, nested string expressions, similar to what you can do numerically in a MATH box.
-
1. Search and replace function for strings, with multiple matches/replacements per string. Wildcards in the search string would be nice too.
2. More complex, nested string expressions, similar to what you can do numerically in a MATH box.
Can you give some examples of each these?
-
I would like to see the "Set Node and IP Configuration" in "System Configuration" also, even if it is just a link or pointer. It takes me forever to find it since I am looking to make a change, not get "System Info".
I know it is sort of already there in "Ethernet I/O Master" but if I'm not doing that type of system it also doesn't occur to me to look there.
(I have the same problem with HMIs hiding their Ethernet setup also, so maybe it's just me.)
-
1. Search and replace function for strings, with multiple matches/replacements per string. Wildcards in the search string would be nice too.
2. More complex, nested string expressions, similar to what you can do numerically in a MATH box.
Can you give some examples of each these?
1. Assume SS0 = "12345678901234567890". Then a STRREP function such that STRREP SS0 "1" "AA" returns "AA234567890AA234567890" and can be assigned to SS0 or SL1 or whatever. I originally got the idea while trying to replace NULLs (ASCII 0x00) with spaces. However, I came to think that maybe replacing NULLs is a special case for two reasons. They may give your C-based searches grief, and second, because 0x00 may be the default for unused character positions in the string. Thus, the specific case of NULL replacement might be better addressed by a STRPAD function (pad with so many of a specified character, or pad to some specified total string length).
2. In the same scenario mentioned above, I did a STRTRIM to get rid of the NULLs, followed by appending enough spaces to fill out the string to the allocated length (not the string .MaxLen) using STRPRINT, then STRTRUNC to the desired length. Kind of roundabout.
STRPRINT now essentially takes a list of discrete items and smashes them into the string, with or without intervening spaces, while allowing for some printf style formatting functions. I'm asking for STRPRINT to take
STRTRUNC(STRTRIM(SS0) + STRFILL(" ", 20), 20)
or even
STRTRIM(SS0) + STRFILL(" ", 20 - SS0.Length)
and the like as its expression. (My STRPAD function could also be used here, this is just an example of the more complex expressions I'm asking for) That way you could get a lot done in one shot. Analogous to how a MATH box replaces a stack of 6 individual instruction boxes like ADD and MUL.
*Note that STRFILL() function to generate in an expression a string containing repeats of a specific character or substring.
-
I would like to see the "Set Node and IP Configuration" in "System Configuration" also, even if it is just a link or pointer. It takes me forever to find it since I am looking to make a change, not get "System Info".
I know it is sort of already there in "Ethernet I/O Master" but if I'm not doing that type of system it also doesn't occur to me to look there.
(I have the same problem with HMIs hiding their Ethernet setup also, so maybe it's just me.)
It's not just you. It took me the longest time to get used to looking in System Info cause it feels like the wrong place for the IP address. I'd like to see it moved and or copied to System Config too.
-
So, I just learned an important thing about the Do-More. The PLC memory image is not stored in the Project file! Without going into detail, I'll just say I learned this "the hard way." Not sure how I've never noticed it before... :P
A discussion of my woes with AutomationDirect technical support led me to recognize the importance of the Memory Image Manager and I now have an image stored that contains all of the values that I'll need whenever I set up a new processor.
That said, I'd like to offer the following suggestions to streamline using the Memory Image Manager, based on my current understanding of how it works:
- Given the importance of the MIM, don't hide it under Tools! It deserves an icon -- preferably one that also functions as a visual alert if data stored in retentive ranges is "stale," similar to the System Configuration (S,P,D) icons in the Status Bar.
- Option check-box in the MIM to "Always refresh all regions image during save," which would do exactly what it says. And/Or...
- Option check-box in the MIM to "Always refresh selected regions image during save," which would add a check-box to each listed region that the user could use to include/exclude auto-refresh regions. And/Or...
- Option check-box in the MIM to "Always prompt for refresh during save," which (when I save the project) would present a prompt to/not-to refresh (all or selected) regions during the save.
-
So, I just learned an important thing about the Do-More. The PLC memory image is not stored in the Project file! Without going into detail, I'll just say I learned this "the hard way." Not sure how I've never noticed it before... :P
A discussion of my woes with AutomationDirect technical support led me to recognize the importance of the Memory Image Manager and I now have an image stored that contains all of the values that I'll need whenever I set up a new processor.
That said, I'd like to offer the following suggestions to streamline using the Memory Image Manager, based on my current understanding of how it works:
- Given the importance of the MIM, don't hide it under Tools! It deserves an icon -- preferably one that also functions as a visual alert if data stored in retentive ranges is "stale," similar to the System Configuration (S,P,D) icons in the Status Bar.
- Option check-box in the MIM to "Always refresh all regions image during save," which would do exactly what it says. And/Or...
- Option check-box in the MIM to "Always refresh selected regions image during save," which would add a check-box to each listed region that the user could use to include/exclude auto-refresh regions. And/Or...
- Option check-box in the MIM to "Always prompt for refresh during save," which (when I save the project) would present a prompt to/not-to refresh (all or selected) regions during the save.
Regarding the toolbar button preferences, the toolbars are completely configurable. You can add (or remove) any command to any toolbar, including Offline and Online.
If you want to add Memory Image Manager to the Online or Offline toolbar, first create a New (empty) project or open an existing one.
1. Right click in the toolbar area. Select Customize...
2. Hit the Commands tab
3. Select the Tools entry in the Categories list box.
4. Look for the Memory Image Manager in the Commands list. Click on it and hold down the mouse button and drag-and-drop it onto the Offline or Online toolbar, wherever you want it to be.
5. The button text will be way too long, so right click on the dropped button (the dropped button takes on the "tooltip" name, not the "short" button name, oops!), and in the context menu, and change the "Name:" field to "Memory Mgr" (or whatever) so it doesn't take up half the screen.
6. Close the Customize dialog
Now you have your own customized toolbar with the Memory Image Manager where you want/need it!
We are planning to have the next version of Designer to have Memory Image Manager available offline, with the ability to edit bit blocks, numeric blocks, and string blocks in the MIM.
Regarding what/when we save the Memory Image, we are looking to address this, among other save/load issues in a future release.
-
I would like to see the "Set Node and IP Configuration" in "System Configuration" also, even if it is just a link or pointer. It takes me forever to find it since I am looking to make a change, not get "System Info".
I know it is sort of already there in "Ethernet I/O Master" but if I'm not doing that type of system it also doesn't occur to me to look there.
(I have the same problem with HMIs hiding their Ethernet setup also, so maybe it's just me.)
The simple answer is that the System Configuration isn't simply a place to set things up, it's a particular and critical part of project data. We didn't put the IP config there primarily because it isn't part of that data. If fact, originally we didn't intend for DmD to even set that up at all, NetEdit was the preferred tool...it was added late in the development, primarily as a way to fix busted a IP config via USB.
...however...
We realize that from the user's perspective System Configuration is the place that you "configure the system" and the IP configuration is part of that. We get that and are planning to add a link to the CPU page. It will be in 1.4.
-
So, I just learned an important thing about the Do-More. The PLC memory image is not stored in the Project file! Without going into detail, I'll just say I learned this "the hard way." Not sure how I've never noticed it before... :P
A discussion of my woes with AutomationDirect technical support led me to recognize the importance of the Memory Image Manager and I now have an image stored that contains all of the values that I'll need whenever I set up a new processor.
That said, I'd like to offer the following suggestions to streamline using the Memory Image Manager, based on my current understanding of how it works:
- Given the importance of the MIM, don't hide it under Tools! It deserves an icon -- preferably one that also functions as a visual alert if data stored in retentive ranges is "stale," similar to the System Configuration (S,P,D) icons in the Status Bar.
- Option check-box in the MIM to "Always refresh all regions image during save," which would do exactly what it says. And/Or...
- Option check-box in the MIM to "Always refresh selected regions image during save," which would add a check-box to each listed region that the user could use to include/exclude auto-refresh regions. And/Or...
- Option check-box in the MIM to "Always prompt for refresh during save," which (when I save the project) would present a prompt to/not-to refresh (all or selected) regions during the save.
MIM was added fairly late in the development and isn't nearly as straightforward as reading or writing the memory in fixed memory map units like DL PLCs. MIM was our first shot at answering the basic problem of saving and restoring retentive memory, and while at its core it works pretty well, the level of integration is poor. We know and we're sorry. As was already mentioned, we do have new features due out soon, and we have already discussed plans to greatly improve the integration. We will definitely consider your suggestions, and one way or the other, we will make it easier to control when the memory image is read or written.
-
We will definitely consider your suggestions, and one way or the other, we will make it easier to control when the memory image is read or written.
Thanks! Your dedication to supporting the user community is sincerely appreciated!
-
Don't overlook my requests for new/improved string manipulation, in more detail as requested by franj1. I made a couple comments in a row, and the second post rolled over to a new page, so please have a look at the previous one at the bottom of the previous page when you get a chance. Thanks!
-
Replace could easily happen. Extending the scripting could happen. Nesting is harder.
-
Very cool! Can you go into more detail on what enhancements are feasible and where the line is between that and nesting? Thanks!
-
Nesting requires some form of stack. A stack of strings is hard. Any script function that doesn't require a stack is manageable.
-
Gotcha -- thanks! :)
-
My project has been using the Do-More for about two years now, as the lead programmer, I am very happy with all the features of the Do-More Platform.
The only features I would recommend adding / changing:
-Configuration of the Closed Loop controller. In DirectSoft, there seems to be many more options for configuring the parameters associated with the closed loop controller. The primary one I see missing is the selection of Data Formats – Unipolar / Bipolar. Most of the closed loops we use control levels above and below a set-point.
I would like to see the ability to select unipolar / bipolar data formats for the different parameters of the Closed Loop Controller.
Password Protection, is it possible to increase the password length to 14 or 15 characters?
-
My project has been using the Do-More for about two years now, as the lead programmer, I am very happy with all the features of the Do-More Platform.
The only features I would recommend adding / changing:
-Configuration of the Closed Loop controller. In DirectSoft, there seems to be many more options for configuring the parameters associated with the closed loop controller. The primary one I see missing is the selection of Data Formats – Unipolar / Bipolar. Most of the closed loops we use control levels above and below a set-point.
I would like to see the ability to select unipolar / bipolar data formats for the different parameters of the Closed Loop Controller.
Password Protection, is it possible to increase the password length to 14 or 15 characters?
All loops are bipolar. The bipolar/unipolar configuration isn't for the loop, it is for interpreting the analog input, since the loop code handles that directly in DL. In Do-more, any tweaking of the analog input can be handled outside the loop, and is generally not required at all. The only case I am aware of is if the input is 16 bit unsigned, you have to cast the WX to unsigned using :U.
The passwords would be fairly hard to change at this point.
-
Seems like it would be convenient to have systems tasks $Daily, $Weekly, $Monthly, and so on. Not hard to do now, but it would bring the same level of convenience and organization that's available now for $TopOfScan, $BottomOfScan, and so on.
I certainly do this often for Once-A-Day tasks now, and could see some wanting weekly, monthly, and so on.
-
The main issue that I could see with those types of tasks would be; "When?"
Do they fire off at Midnight? Sometime randomly during the day? Do you get to set a time?
-
My thinking was either you get to set the time via a dialog somewhere, or it's non-configurable and runs at midnight for dailies, 12:00:00.001 Sunday morning for weeklies, 12:00:00.001 on the first for monthlies, etc.
Another thing I take into account when I do dailies is what happens if the PLC is off at the designated time (typically midnight). It may be something you still want to run as soon as the PLC is up, so if it's one of those things, I track the date of last execution, and do the task on power up even if not at midnight. So, how (or if) to handle that issue is something you'd have to decide.
-
I would like to see $daily, $weekly, $monthly functions with a selectable start time. I've had to do this for billing customers based on peak daily flows and monthly total flows.
-
It would be handy for pipelines and other utility services as well as for certain data logging applications. I could have certainly used it at my last job which required EPA record keeping.
-
I would like to see $daily, $weekly, $monthly functions with a selectable start time. I've had to do this for billing customers based on peak daily flows and monthly total flows.
It's not that hard to do.
For daily:
STRE $Now.Hour == DesiredDailyHour
RUN DailyProg
For Weekly:
STRE $Now.DayOfWeek == DesiredWeekDay
ANDE $Now.Hour == DesiredWeeklyHour
RUN WeeklyProg
For Monthly:
STRE $Now.Day == DesiredDay
ANDE $Now.Hour == DesiredMonthlyHour
RUN MonthlyProg
Just make sure you stick EXIT instructions inside each of the Programs when they are done doing whatever it is they need to do.
The Desired* values can be a V location (for a configurable desired time), or a Symbolic Constant or just a constant (for a fixed time).
-
True, but the existing system tasks aren't hard to write from scratch either. The only advantages I see to systems tasks are two: that they do save you a LITTLE work, plus they promote an organized program. Same logic applies to all of these, pro or con, as to the existing system tasks.
-
I can see both sides of this. But I prefer to write it myself if I need the functionality. I do like the idea of "code snipets" though. If there was a way to build an internal library for DMD that could store custom snipets as well as downloadable snipets of common tasks, this would keep the internals of DMD clean, but make it easy to get anything you wanted.
-
I think the best answer is to not do these things as built-ins, but to invest time in developing reuse mechanisms. Having a template or macro system would allow you to create your own reuseable objects to exactly your specifications. If those objects happened to show up in the project tree the same way as the system tasks, the two would be virtually indistinguishable in practice.
-
Siemens calls that a "library", saving custom boxes for reuse. You can protect them or not, as desired.
I agree that having that is more valuable than some specific new system tasks.
-
I dreamed of having a library back when I was actively developing code. Shoot, I still dream of having one just to store code snippets to send to customers. ;D ;D ;D
-
Or, the entire library typically becomes one file, so just put the whole thing on the website and let people download it and browse the snippets. They might find one they didn't even know they needed. Just add functions to it when you come across good ones. Or keep library files by types of functions.
-
Or, the entire library typically becomes one file, so just put the whole thing on the website and let people download it and browse the snippets. They might find one they didn't even know they needed. Just add functions to it when you come across good ones. Or keep library files by types of functions.
I love the idea of having a code library file up for easy download. They say that experience is the greatest teacher, but no one ever said it had to be personal experience. I'd be happy to see how other people do things.
-
We've always planned to (eventually) support a code library. But I also like the idea here of multiple libraries, where there is a local one, and then a COMMUNITY one that EVERYONE can access via the INTERNET. That would be cool.
We are looking to add FUNCTIONs and SUBROUTINEs in a future release (think user defined MATH functions and user defined BOX INSTRUCTIONs, aka Function Blocks). Functions and Subroutines would make the library concept even MORE POWERFUL. We will do Functions and Subroutines before we implement Library functionality.
-
What I'm picturing IS a library of custom functions and subroutines. That's what Siemens' libraries are; just more groups of functions you can open like the native ones in the same spot you open the native ones, not a management tool for bulk code snippets. That wouldn't be a absolutely terrible idea, but far, far less important than function block libraries.
-
How about a "rung monitoring window" that you could copy rungs into (not necessarily sequential rungs, or even from the same task or program). Don't get me wrong data view is great, but it would be great to see the "status" of multiple rungs from different areas at once for troubleshooting.
-
How about a "rung monitoring window" that you could copy rungs into (not necessarily sequential rungs, or even from the same task or program). Don't get me wrong data view is great, but it would be great to see the "status" of multiple rungs from different areas at once for troubleshooting.
Good idea. These things may also be helpful:
1. Under the Window menu choose Cascade to put the ladder views into old-style MDI mode. This allows you to view multiple ladder views at once.
2. Dragging the little bar at the very top of a ladder view scroll bar will split each view into two panes, allowing you to view different areas of the same code block.
3. Right click on a rung and select Monitor Values, and there are options for automatically loading rung/instruction contents into a Data View.
-
Good idea. These things may also be helpful:
1. Under the Window menu choose Cascade to put the ladder views into old-style MDI mode. This allows you to view multiple ladder views at once.
2. Dragging the little bar at the very top of a ladder view scroll bar will split each view into two panes, allowing you to view different areas of the same code block.
3. Right click on a rung and select Monitor Values, and there are options for automatically loading rung/instruction contents into a Data View.
[/quote]
Number 2 does help, did not know you could split a window into 2 panes (do you have D0-More for Dummies yet).
-
Please include the ability to enter the "Extra Info" and "Description" to the "Create Nickname" dialog box.
-
Please include the ability to enter the "Extra Info" and "Description" to the "Create Nickname" dialog box.
Already in the code. Will be in the DmD 1.4.
-
Speaking of editing, I find that when copying tags adding the leading underscore and a trailing digit wastes a ton of time when revising the tag. Typically when I copy a tag it is because most of it is useful and just the least significant characters get changed. Having to delete the leading underscore is a nuisance.
-
Speaking of editing, I find that when copying tags adding the leading underscore and a trailing digit wastes a ton of time when revising the tag. Typically when I copy a tag it is because most of it is useful and just the least significant characters get changed. Having to delete the leading underscore is a nuisance.
Hear, Hear! Me too.
I wind up selecting the original tag to edit, highlighting what I need (all of it), canceling, then pasting as a new tag and editing that. Also a major waste of time though.
-
Sorry guys. Tags have to remain unique. The trailing digit is to ensure uniqueness. The leading underscore is to make it clear that these have been modified by the software and need user attention. Imagine copying a rung into a large project, and having 5 out of 500 tags modified for uniqueness. Needle in a haystack. The way we do it makes it easy to find and fix those.
-
Bob, I have found the same as these other fellows. Could the underscore be added to the ending instead? The part that makes it such a pain is having to edit the first character AND the last character.
-
Bob, I have found the same as these other fellows. Could the underscore be added to the ending instead? The part that makes it such a pain is having to edit the first character AND the last character.
It isn't required. It was just there to make them stand out. We'll see if we can talk Mark into making that an option.
-
Yeah, this one bugs me too. I realize the nicknames must remain unique (because they can be used for alternate addressing), but the way it's done now feels very unwieldy, and if some more user-friendly idea could be found, I agree that it would make users lives easier.
Thanks! 8)
-
Actually, rather than spend effort optimizing stuff like this, I'd vote for upgrading the doc Import/Export facility. (Primarily by putting description line breaks in separate columns rather than embedding a control character. Much easier to read and also much easier to use Excel drag-and-fill one column at a time if it's done that way).
For decades, I've used the external CSV copy as the official version of Allen-Bradley docs (Siemens too) and only import to the programming package, and not use the internal editor at all. All that editing UI for tabular data is there for the using in spreadsheets, why not leverage it, instead of expending a lot of effort reinventing it?
-
Actually, rather than spend effort optimizing stuff like this, I'd vote for upgrading the doc Import/Export facility. (Primarily by putting description line breaks in separate columns rather than embedding a control character. Much easier to read and also much easier to use Excel drag-and-fill one column at a time if it's done that way).
For decades, I've used the external CSV copy as the official version of Allen-Bradley docs (Siemens too) and only import to the programming package, and not use the internal editor at all. All that editing UI for tabular data is there for the using in spreadsheets, why not leverage it, instead of expending a lot of effort reinventing it?
It already does this as an option on export, and implicitly does this on import.
-
Really? Awesome! When was this added? That was a request of mine a long time ago and I didn't realize it was ever done.
Since you do have that, I'm not sure you need to change how the internal docs editor works. It seems to me like that solves the problems of users like me who don't like the way the automatic nickname disambiguation works, just use Excel or Open Office for the docs editor. Much better editing capabilities anyway, plus it doesn't know to differentiate the nicknames so it gives you the chance to do it yourself in whatever way you like before importing to DMD or DSoft. (Plus the drag and fill may give you the opportunity to do it almost effortlessly anyway)
-
I don't know. Does this mean we don't need spell check because we can always just look it up in a dictionary?
(Not that spell check works worth a darn, since people are usually using the wrong words to benign (sic) with.) ;)
My vote goes to ditching the leading underscore - optional is fine. I usually don't do this type of thing wholesale anyway. Yes, if I do need to do a bunch, I use an external spreadsheet. In the days of old I would write a program in QuickBasic to do it.
But then it gets back to my wanting to have Drive1 Drive2, etc., for which I've already had my hand slapped. Maybe we could get smart-sorting that knows the proper order is DriveI DriveII DriveIII DriveIV, etc.? ::)
-
I don't know. Does this mean we don't need spell check because we can always just look it up in a dictionary?
(Not that spell check works worth a darn, since people are usually using the wrong words to benign (sic) with.) ;)
My vote goes to ditching the leading underscore - optional is fine. I usually don't do this type of thing wholesale anyway. Yes, if I do need to do a bunch, I use an external spreadsheet. In the days of old I would write a program in QuickBasic to do it.
But then it gets back to my wanting to have Drive1 Drive2, etc., for which I've already had my hand slapped. Maybe we could get smart-sorting that knows the proper order is DriveI DriveII DriveIII DriveIV, etc.? ::)
Names have to be unique, but how we accomplish it is completely arbitrary. When we added the leading underscore, we did so to solve a perceived issue that clearly isn't as big a deal as the problem we caused doing so. We'll change it.
So who slapped your hand?
-
I don't know. Does this mean we don't need spell check because we can always just look it up in a dictionary?
Well, I just feel that if there's already a superior tool for editing tabular data, why spend effort upgrading the runner up that could be spent on adding features that MUST be in the programming package?
My vote goes to ditching the leading underscore - optional is fine. I usually don't do this type of thing wholesale anyway. Yes, if I do need to do a bunch, I use an external spreadsheet. In the days of old I would write a program in QuickBasic to do it.
Yup, me too, though in my case it was VB and VBA. I've even done AB code generation in VB.
-
So who slapped your hand?
Some guy that goes by BobO back in Reply #232. ;D
[Quote from: Mike Nash on 2014-09-25, 16:58:12
Yes I would love to have Add On Instruction ability, and User Data Types (say Drive_2.AccelTime etc.) And not being able to have a User Memory type with a number in the name is a drag (Drive2).
User data types and functions are coming in DmD 2.0.
Because we don't use a token to delineate normal array type memories (X0 vs X[0]) it becomes very difficult to parse if you allow numbers in block names. If I have MyBlock2 and MyBlock22, what does MyBlock221 reference? As much as we would like to support it, sanity must prevail. I would say that user data types will help to a significant extant.
"Slapped my hand" was tongue in cheek, for which I see no emoticon. And yes, I was asking for something slightly different previously.
-
Well, I just feel that if there's already a superior tool for editing tabular data, why spend effort upgrading the runner up that could be spent on adding features that MUST be in the programming package?
I will field this one. @Controls Guy, trust me when I say that you are pretty advanced in your knowledge of PLC's. For most users they don't want or even sometimes know how to drop a program or documentation into Excel and edit it. The thought has never occurred to them that it might be possible.
This isn't to say that anyone is dumb either. It's all a level of programming efficiency and suitable mentoring. I know when I first started at AutomationDirect, I thought I knew a fair amount. After a month there, I felt like I was just a beginner again. I learned an amazing amount from the other Tech Guys as well as from users that I talked to on the phone. Almost 13 years later my programming efficiency is incredibly more advanced than I ever would have achieved on my own and I had been programming everything from Mainframe computers, PC's to PLC's since the early 80's.
Let's say for argument's sake that 5% of a particular device's users are beginners. 15% are "Experts". That leaves 80% as some sort of intermediate user. In that 80% there is an amazing diversity of ability. Now let's postulate that of that 80% intermediate that only a handful are going to make it to "Expert" status. The rest are stuck in what one author has called the "perpetual Intermediate" state. That is to say that they will never have enough time, willingness or for some some other reason just cannot make to being an "Expert". Maybe it's because like a lot of people doing controls work they have to wear too many hats.
"I'll only get to send a week programming this PLC, then I have to make final documentation, do the start up and then on to my next project." This guy just can't get enough time in to advance properly. But. He is still a competent programmer who does a fair amount of business buying PLC's and programming them for a living.
So wind this whole thing up, we (ADC and HOST) have to accommodate a very large span of users who have incredibly different programming styles and competency levels. We would be shooting ourselves in the foot just to cater to the 15% of the "Experts" or the 5% of the "Beginners". We can't ignore the Beginners or the Experts, but we can't just make features that only appeal to either group as well and do nothing for the Intermediates. Therefore my vote would be to ditch the leading underscore and make the documentation editor just a little bit more friendly for everyone involved.
-
@Mike Nash
Hand slap? Nah...just felt like that 'cause nerd-speak is so tedious.
You will be able to do what I think you originally wanted, using user types, allocated from heap. Imagine something like Drive1.Speed or Drive1.Position. Goal is still DmD 2.0 for that.
@Everyone
We are adding fill to the doc editor for this release. You will be able to create a doc record (nickname == Booger), then do a spreadsheet style fill to create Booger2, Booger3, etc. It won't replace Excel for heavy duty stuff, but should be helpful for most.
And we will definitely drop the underscore. We predict 173% of the issues you guys face...and try to solve them all. For the most part, y'all are unaware of the 100% (it just worked) and unaware of most of the 73% (never needed it, but didn't hurt you)...but there are a few that we tried to fix for you that just annoyed you. We repent...
-
Really? Awesome! When was this added? That was a request of mine a long time ago and I didn't realize it was ever done.
Probably right after you requested it, maybe even 1.0 ;D.
I just checked, the Export->Project command ALWAYS does the element documentation in the multi-column form (no option), cuz since you are exporting the PROJECT, you probably want to IMPORT it back into Designer, maintaining any multi-line element Description formatting.
However, the Export->Element Documentation may be for a database or for re-import or who knows, so it has two options:
o Standard Format (Description is just one CSV field, any CR/LFs replaced with a space)
o Standard Format PLUS export multi-line Description as multiple CSV fields (can't get more descriptive than that, eh? ;D)
Just checked - the feature was in 1.0 ;D.
3 Cheesy Grins in 1 post. I think that's a record for me ;D! (make that 4)
-
Probably right after you requested it, maybe even 1.0 ;D.
No, this was in early 2006 relative to the release of DirectSoft (5?). I didn't see it in DirectSoft after that and just never realized it was in DMD. Did this get added in DSoft as well?
Appreciate the change and the heads up -- this makes life easier! :)
-
"I'll only get to send a week programming this PLC, then I have to make final documentation, do the start up and then on to my next project." This guy just can't get enough time in to advance properly. But. He is still a competent programmer who does a fair amount of business buying PLC's and programming them for a living.
I don't necessarily disagree with any of what you posted (the entire post, not just what I quoted), but having said that, I'm still of the opinion that:
1) The best overall collection of tools benefits everyone at every level of familiarity/proficiency. Since outside editing is there, it seems like that moves upgrades to the internal docs UI to a different place in the 80/20 spectrum.
2) The people who don't like the existing nickname disambiguation are probably the same high-volume users who don't mind using Excel. The casual user probably doesn't mind the way it is now.
So in short, I try to look at requesting things from a bang-for-buck point of view because I know there's only so many development personnel and hours available, and try to request only the things that are the most critical to me and for which there isn't some efficient existing alternative. I found out there was an existing efficient alternative so backed off on suggesting additional work here.
-
Did this get added in DSoft as well?
Sorry, no.
-
Did this get added in DSoft as well?
Sorry, no.
No apology required -- I have no particular plans to use DL classic PLC's much if at all in the future (Do-More rocks! ;D). I just thought that if it didn't get added, that was probably why I never thought to try in DMD.
-
"I'll only get to send a week programming this PLC, then I have to make final documentation, do the start up and then on to my next project." This guy just can't get enough time in to advance properly. But. He is still a competent programmer who does a fair amount of business buying PLC's and programming them for a living.
Me to a T, only the time span is in the range of 4 to 6 months typically. So my skill set plateaued a long time ago. The same for Excel, Word, Rhino3D, AutoCAD, SolidWorks, and CamBam unfortunately.
Also at this job I have almost no infrastructure to fall back on. You want an AutoCAD drawing? First I have to create a title block for the sheet sizes we can print. SolidWorks drawing? Same deal. Fill out a timecard? Okay but first I have to create a timecard! PLC programming? First I have to select a PLC, draw a wiring schematic, do a process description, learn a new programming package, on and on. If people could just understand how long this all takes it would be fun.
-
80% of our users fall into the "perpetual immediate" category, and they are our focus. The challenge is in building something that noobs can use and experts don't hate, while catering to smart guys who write PLC code about 10% of the time.
-
80% of our users fall into the "perpetual immediate" category, and they are our focus. The challenge is in building something that noobs can use and experts don't hate, while catering to smart guys who write PLC code about 10% of the time.
I would have to say that sounds pretty profound! I can think of a few biggy corps that could use some of your insight. ::)
I really appreciate companies that do strive to address issues and implement feature requests in a timely manner. I have dealt with another vendor that added features I desired and fixed issues as they were uncovered and it was very gratifying then also. And yes we still use their product and it actually complements yours. I haven't requested any new features from them lately, but they have already added most everything I was hoping for. ;D
-
80% of our users fall into the "perpetual immediate" category, and they are our focus. The challenge is in building something that noobs can use and experts don't hate, while catering to smart guys who write PLC code about 10% of the time.
I would have to say that sounds pretty profound! I can think of a few biggy corps that could use some of your insight. ::)
I can't take credit. It's from a software design book (which I should know the title of, but don't recall it at the moment). It so obviously applied to our market, we latched onto it and it has become a very significant influence in how we design software now.
-
I can't take credit. It's from a software design book (which I should know the title of, but don't recall it at the moment).
About Face - The Essentials of User Interface Design by Alan Cooper, the Father of Visual Basic (the original one). Don't hold that against him, he complains about Microsoft ALL the time in his book.
-
I haven't been here for a looong time (satified customer). I would like to know if there's anything being done with CAN comunications. We primarily do simple read/write commands and presently use LabVIEW for it. There are PLC's that have CAN capability now and I was wondering if you were going to do it also.
Thaks for ALL the great things you do now.
-
I haven't been here for a looong time (satified customer). I would like to know if there's anything being done with CAN comunications. We primarily do simple read/write commands and presently use LabVIEW for it. There are PLC's that have CAN capability now and I was wondering if you were going to do it also.
Thaks for ALL the great things you do now.
Not opposed to it, although we really don't get much call for it. Are you primarily interested in master or slave?
-
I expect there is a hardware limitation involved, but the 16-character Nickname (without the ability to use any special characters) can get frustrating -- especially in a semi-large program. The Description field often just ends up being a decoder ring for a cryptic Nickname.
There is often wasted effort, where the Nickname and Description contain basically the same information, just in a different format. Example:
- Nickname: MB_C1_PIDP_AC
- Description: ModBus, Clarifier #1, PID P-Gain, Acid Control Loop
The inability to search in the Description field further contributes to the problem(s).
I would prefer to name the variable something like: Modbus_Clarifier1_pHCtrl_PGain_Acid, but that's 35 characters. It also happens to be how the variable is written in the SCADA system I'm using. It would be best if the name were the same in both systems, but it's not worth losing the readability on the SCADA side just to maintain name-sync with the PLC.
Consequently, I'm providing a human-readable version of the name in the PLC Description field, and on the SCADA side I'm listing the PLC variable name in the Tag notes. ::)
-
No hardware limitation. It's on the list of future enhancements.
-
Eggzellent!!! ;D Probably too soon to ask about ETA...?
-
Here's a feature I have thought for a time would be very useful. If any of you happen to read Circuit Cellar or other electronics magazines, you probably seen a hundred different small PLC like microprocessor boards. Every time somebody posts about needing to control something on a forum you have half a dozen people saying "Use an Arduino, you can do that for $20!" The problem is that most of those cheap solutions ignore how much work it is to build real world I/O that takes in to account all the things that PLC I/O does. In the end it is either unsafe, failure prone, or just as expensive as a PLC. And that Arduino board was obsolete and no longer available before they shipped it to you!
So how about the 'Hackable PLC'? A PLC that actually lets you have access to the microprocessor using programming tools like C or Java, or whatever. If the firmware gave you access to all of the I/O modules and communications ports for whatever hardware platform the PLC worked with you could do some really do some amazing stuff, and your I/O would truly be real world, not a hack.
-
Here's a feature I have thought for a time would be very useful. If any of you happen to read Circuit Cellar or other electronics magazines, you probably seen a hundred different small PLC like microprocessor boards. Every time somebody posts about needing to control something on a forum you have half a dozen people saying "Use an Arduino, you can do that for $20!" The problem is that most of those cheap solutions ignore how much work it is to build real world I/O that takes in to account all the things that PLC I/O does. In the end it is either unsafe, failure prone, or just as expensive as a PLC. And that Arduino board was obsolete and no longer available before they shipped it to you!
So how about the 'Hackable PLC'? A PLC that actually lets you have access to the microprocessor using programming tools like C or Java, or whatever. If the firmware gave you access to all of the I/O modules and communications ports for whatever hardware platform the PLC worked with you could do some really do some amazing stuff, and your I/O would truly be real world, not a hack.
That was substantially what the WinPLC was, at least the WinCE version. It did enjoy a small but loyal fanbase, but was not a broad success.
I do see a future platform we are working on that could work nicely for something like this, but the sales and support would be problematic. ADC won't sell it and Host really doesn't have the infrastructure to do so, but perhaps we'll look into it when we have the appropriate hardware.
-
A micro PLC, that is a small 'potted' board with one row of clamp-type screw terminals on it would be awesome. It would only need about 4 inputs with 2 dry relay outputs, and a serial port. The inputs would need to be software configurable as either analog or digital, and the power supply would need to operate on 5 to 24 VDC (automotive applications).
I was looking at one that was only available in Europe, but cannot find the website now...
Pricepoint could probably be ~$80
-
The nano I have mentioned is spec'ed to have 8 in, 4 out. We are hoping to have 4 of the inputs be combined analog and discrete, with configurable comparator thresholds. Ports are still being discussed, but will likely be limited to slave only, but we'll see. It will be an actual Do-more PLC (new DM0 class) in a actual housing, with a target price under $100. It wouldn't be hard at all to take that down further to a 4 in/2 out.
The lowest model of the new platform currently under development will be 6 DI/4 DO, with one model having 1 AI/1 AO. He will cost more, but is a full DM1 CPU. I would like the base model of that under $200, but that is still being determined.
We spent a long time developing Do-more and this is where it finally gets fun. Once you have the technology, adapting it to new stuff like this is easy.
-
A potted, screw terminal board, would be great for applications that are not in a control cabinet and can get wet etc.
-
The nano I have mentioned is spec'ed to have 8 in, 4 out. We are hoping to have 4 of the inputs be combined analog and discrete, with configurable comparator thresholds. Ports are still being discussed, but will likely be limited to slave only, but we'll see. It will be an actual Do-more PLC (new DM0 class) in a actual housing, with a target price under $100. It wouldn't be hard at all to take that down further to a 4 in/2 out.
The lowest model of the new platform currently under development will be 6 DI/4 DO, with one model having 1 AI/1 AO. He will cost more, but is a full DM1 CPU. I would like the base model of that under $200, but that is still being determined.
We spent a long time developing Do-more and this is where it finally gets fun. Once you have the technology, adapting it to new stuff like this is easy.
Any hints as to a release timeline? I am using H2-DM1E's in my current machines and we are looking to make a new smaller machine and it would be GREAT to have a smaller DM that I can just drop our existing program into... Very excited!!!! I love the DM line, and do not use anything else!
Another question, do you plan on having any of the inputs on the DM Nano be high speed inputs? Something that could take a pulse input from a flow meter or something like that. Not super high speed...
-
Any hints as to a release timeline? I am using H2-DM1E's in my current machines and we are looking to make a new smaller machine and it would be GREAT to have a smaller DM that I can just drop our existing program into... Very excited!!!! I love the DM line, and do not use anything else!
Another question, do you plan on having any of the inputs on the DM Nano be high speed inputs? Something that could take a pulse input from a flow meter or something like that. Not super high speed...
We expect the first models out next year. There will definitely be some high speed inputs.
-
We expect the first models out next year.
Q1? ;D
-
On the subject of new platforms:
Am I the only one that hates running wiring to the top and bottom of a PLC?
Maybe there are reasons that are beyond my understanding, but I would much prefer either all the wiring terminals across the bottom of a PLC, or the vertical wiring terminals like on DL205, or the CLICK; but I despise the top wiring on DL05/06 and Micrologix 1200/1500 etc.
Thoughts from other users?
-
Thoughts from other users?
Here's an old poll where this topic was discussed in some detail...
http://forum.hosteng.com/index.php/topic,201.0.html
-
On the subject of new platforms:
Am I the only one that hates running wiring to the top and bottom of a PLC?
Maybe there are reasons that are beyond my understanding, but I would much prefer either all the wiring terminals across the bottom of a PLC, or the vertical wiring terminals like on DL205, or the CLICK; but I despise the top wiring on DL05/06 and Micrologix 1200/1500 etc.
Thoughts from other users?
Bricks tend to favor board arrangements that work better with split terminals. Modulars generally like vertical arrangements. Our new system will employ both.
-
Ah Franji1, I had forgot about that one...
I did not see any discussion there concerning the wire terminal location though.
I guess I'm just hinting that I would much prefer the vertical terminal blocks...
-
Am I the only one that hates running wiring to the top and bottom of a PLC?
Maybe there are reasons that are beyond my understanding, but I would much prefer either all the wiring terminals across the bottom of a PLC, or the vertical wiring terminals like on DL205, or the CLICK; but I despise the top wiring on DL05/06 and Micrologix 1200/1500 etc.
Thoughts from other users?
You're not the only one, although for me, it's not the top+bottom that offends, it's just the low-density linear arrangement period. I guess for me, bottom-only would be even worse. Coming from PLC-5's and TI5x0/5x5's where you can get hundreds of I/O points, with probe-able screw terminals, in a square foot of PLC front, I really dislike the brick form factor. I discussed this point once with BobO, and he said that it's far more expensive to do perpendicular connectors due to the likely arrangement of circuit boards inside the housing.
-
Housing design for bricks is problematic and just generally works better with horizontal boards and terminals. I totally understand the frustration.
The new platform will have 3 sizes of bricks (the smallest has vertical terminals like Click), but also a modular only CPU/PS combination ala DL405, that will make it possible to do purely vertical. I have zero doubt that we will sell way more horizontal terminal bricks than the modular CPU, because in the end cost almost always wins out. I would
-
I appreciate you guys giving us the option to do purely vertical and mostly vertical systems. People often do weird things when trying to analyze costs, like trying to do a separate analysis on each part, assuming that the lowest/best product will be created by choosing each individual lowest cost part. Doesn't really work, IMO. I don't want the absolute cheapest part, I want the best price I can get on the part with the characteristics I actually want. The other way is short-sighted IMO.
-
One of my customers is an integration company that uses a lot of Siemens. The owner was talking to a customer about some application that some previous integrator had really hosed up with a Click, to the point where the poor customer didn't think a PLC could do the app. This guy said "Well, as long as you don't try to do it with the $69 one, a PLC can definitely do this job."
(Now that's not a swipe at DM1 design in any way, but rather an example of the goofy-butt way users who don't know what they're doing try to optimize costs)
-
One of my customers is an integration company that uses a lot of Siemens. The owner was talking to a customer about some application that some previous integrator had really hosed up with a Click, to the point where the poor customer didn't think a PLC could do the app. This guy said "Well, as long as you don't try to do it with the $69 one, a PLC can definitely do this job."
(Now that's not a swipe at DM1 design in any way, but rather an example of the goofy-butt way users who don't know what they're doing try to optimize costs)
We'll be sure to keep our most affordable Do-more above $69. ;)
-
One of my customers is an integration company that uses a lot of Siemens. The owner was talking to a customer about some application that some previous integrator had really hosed up with a Click, to the point where the poor customer didn't think a PLC could do the app. This guy said "Well, as long as you don't try to do it with the $69 one, a PLC can definitely do this job."
(Now that's not a swipe at DM1 design in any way, but rather an example of the goofy-butt way users who don't know what they're doing try to optimize costs)
We'll be sure to keep our most affordable Do-more above $69. ;)
My boss was like that when he first hired in, he hated our DL Plc's cause he thought they were cheap and a few times he flat out refused to buy the click because it was in his words "Cheap and Plastic."
Our main welding line uses a S7 Plc and to replace the CPU when it had a hardware fault was more that all the PLC setups in 6 of it's support machines combined and they have run 6+ years without much more than a relay output card going bad, he realized that maybe price isn't what determines quality.
-
My boss was like that when he first hired in, he hated our DL Plc's cause he thought they were cheap and a few times he flat out refused to buy the click because it was in his words "Cheap and Plastic."
Our main welding line uses a S7 Plc and to replace the CPU when it had a hardware fault was more that all the PLC setups in 6 of it's support machines combined and they have run 6+ years without much more than a relay output card going bad, he realized that maybe price isn't what determines quality.
There is definitely a point at which inexpensive can become "cheap", but we try very hard to not go there. The key with any product is to use it for what it was designed for. When people try to use Click for a Do-more class app, somebody's feelings are gonna wind up getting hurt.
-
My boss was like that when he first hired in, he hated our DL Plc's cause he thought they were cheap and a few times he flat out refused to buy the click because it was in his words "Cheap and Plastic."
Well, I'd go along with "Cheap and Plastic". Not cheap BECAUSE it's plastic, but it is cheap/cheesy and it is plastic. (and it's certainly reasonable to believe that a lot of compromises and features would have to be left out to sell something at that price point)
I've used the current Siemens offering (which starts at about $200), and I can tell you I'd pay AT LEAST 10 times for one of those what I'd be willing to pay for a Click. Maybe 20x. It's a professional, quality product.
-
Although I have pieced together my own web server post functions,
It may be nice to have a built in module that would help facilitate this kind of communication.
-
We've discussed adding HTTP GET and POST instructions. Biggest holdup is not being completely how people want to use them and how many people would. Don't want to add something that isn't useful.
-
My boss was like that when he first hired in, he hated our DL Plc's cause he thought they were cheap and a few times he flat out refused to buy the click because it was in his words "Cheap and Plastic."
Well, I'd go along with "Cheap and Plastic". Not cheap BECAUSE it's plastic, but it is cheap/cheesy and it is plastic. (and it's certainly reasonable to believe that a lot of compromises and features would have to be left out to sell something at that price point)
I've used the current Siemens offering (which starts at about $200), and I can tell you I'd pay AT LEAST 10 times for one of those what I'd be willing to pay for a Click. Maybe 20x. It's a professional, quality product.
I'm assuming your using the Siemens LOGO unit (I think that's what it's called)? Our sister plant upgraded one of our machines to use one. I would have went Do-More but wasn't my project. But they are nice simple units.
But for the Click, we have them in shop, but mostly for small simple projects. But they have limitations and we have had some hardware issues of I/O points failing.
Honestly they make great diagnostic tools that we use to trouble shoot some of our other machines. Currently we have a counter in one of our welders that sometimes stops counting. Contacted OEM to get some advice (Program notes are in german on an S7, something I'm not too familiar with.) They told me that the input(s) to the counter were acting up.
Well after some troubleshooting, I wired a click up to the same input terminals and emulated the function of the counter and turns out the inputs were fine, but rather when they upgraded the program there were a few bugs...
-
I'm assuming your using the Siemens LOGO unit (I think that's what it's called)? Our sister plant upgraded one of our machines to use one. I would have went Do-More but wasn't my project. But they are nice simple units.
No, I'm talking about S7-1200s! $200 for the low end! Very competitive with a Do-More, capability and speed-wise. User-defined types, library functions, user and predefined system tasks, large selection of built-in data types, built-in Ethernet. Structured Text programming, etc. The only place they come up short vs. a Do-More is memory on the low end units, and (in the case of the 1200s only), the brick PLC style wiring along the top and bottom, vs. real PLC vertical terminal arrangement. I have one product where I need one analog but otherwise a brick PLC is fine, and they have two (10-bit, voltage only) built-in. Basically it's like a DM1 that I can buy now.
Call me a PLC snob if you want, but I never really use smart relays like the Logo. They're priced about the same as an inexpensive PLC and do far less, so what's the point? I do know some people who like them for the simplicity, but I think a lot of that is that they're used to the smart relays and if they used PLC's once or twice, even that advantage would vanish.
-
DM1?
Thats why that maintenance manager used it I think was the simplicity. His PLC skills are very lacking.
Back when the machine was ours, I suggested gutting all the wiring and starting over. Wiring that had been oil soaked and at least 50 years old, insulation falling off.
But I did plan on putting a DM in, just for the expansion capacity. You never need as much IO as you plan for, you need double!
Honestly a DM would be way overkill for that application, as it was nothing more than conversion of simple relay logic. Total of about 15 relays I think in the whole control cabinet.
Sad part was that I had to fly out to New Mexico and help program that machine and get it running.
-
DM1?
I think he was referring to the brick in development.
-
Thats why that maintenance manager used it I think was the simplicity. His PLC skills are very lacking.
Wait, what? He like smart relays, but Clicks are bad because they're cheap and plastic??? I assumed he was throwing PLC-5's at every project or something.
(https://forum.hosteng.com/proxy.php?request=http%3A%2F%2Fm.memegen.com%2F8g6oee.jpg&hash=6476dbde721ea55a6ab8d1532afaea06a1971769)
-
Let me give you some examples of how this guy thinks:
1.) Spends $5000 on a custom stainless steel water header pipes and fittings for this welder. Can't use the DM because of cost issues.
2.) Installs a 2 channel estop system and instead of putting the reset on the operator console he puts it on the control cabinet, one that you have to walk around the entire machine to access when it has wire loaded in it to weld.
3.) Puts a second LOGO unit in the operators console just to act as a counter... with a display screen that after six months can't control when the machine cuts.
4.) Speaking of automatic shearing of mesh sheets... Finally he gets the counter section of the program working. He can't get the shear to cut via the plc but he can make a light flash on the control panel letting you know that you need to manually push a button marked "Cut".
5.) The machine is fed from 480vac 850amp supply. The 24vdc control power supply was fed from an extension cord through the wall to an outlet on the other side of the bay. 15 times the whole machine shut off due to someone unplugging the cord... All the while there is a 480-120 transformer about 2ft under the power supply in the cabinet.
6.) Added 12 or so new 22mm lights to control panel, and when I asked what they were for he told me, "Nothing now, but don't worry I'll find use for them"
This machine had 15 relays inside, and it only used 4 of them. The wiring prints fit neatly on a 11x17 page. Now there are 30+ relays, 2 LOGO units, 2 small HMI screens, and about half of it works.
Yeah, that's what our new sister plant does.
-
Let me give you some examples of how this guy thinks
1) I'm pretty sure 'thinks' should be quoted.
2) I saw the 12 lights thing and I thought "crap, 12 lights would pay for an HMI!", then later I saw there already were a couple. D'oh!
Wow. Peter principle in action. Looks like a future customer for me.
I remember this one machine I got called on for a service call one time. Indexing table with a press cylinder to assemble two parts, and it wasn't working consistently. Couldn't really figure it out because no prints, no wire numbers and all the wires were black. Started tracing out the circuits. Find out half the wires are dead ends so can safely be ripped out. Then find several other circuits, while not mechanically dead ended, are effectively so, because they run through both a NO and a NC on the same relay or something like that. Can never actually carry current anywhere. Rip THOSE out, and now the noise level is diminishing to the point that I'm starting to see what the logic is. See there's a simpler way to do it, and rip a bunch MORE out. End up with two photos (one with a one-shot function programmed in) driving two relays driving two air valves, the table and the press. I could have thrown out the relays if I thought the photos would drive the valves reliably. The machine never missed a lick after that! This story isn't really analogous to yours, except in displaying the Peter principle at work.
-
Funny how this stuff happens and is so similar. Went on a trouble call at a fire house because the radio wasn't being triggered when a fire call came in. They had all this electrical equipment that had been changed many times, and some of the wiring was zip cord from a lamp! The guy who called me left the room and I reached in my toolkit for the cutters and when he returned there was a big ball of wire on the floor. He says "Oh My God! I hope you know what you are doing" I put back about 1/10 the wiring nice and neat and it all worked as it should again.
-
"Oh My God! I hope you know what you are doing"
LOL. My response to that was always; "It ain't working now, so how bad can I hurt it?"
-
"Oh My God! I hope you know what you are doing"
LOL. My response to that was always; "It ain't working now, so how bad can I hurt it?"
I have heard that more than once, but once they see that there is a method to your madness, they tend to let you work.
When I redid one of our wire drawing lines, I tore every single wire out of the cabinet and loaded it into a 55 gallon drum. The wiring left was the bundles that came from the external components like motors and the control panel. Told him nah, come back in 72 hours and watch it run. He told me it could never be done.
All he saw was the empty cabinet, what he didn't see was the hundreds of hours I had spent prior... Drawing up the prints, building the cabinet in AutoCad, laying out where everything would go, Etc. Already built the terminal strips on the din rail.
Now when he sees me with that mad glean in my eye looking at our latest project, he just smiles and gets out of the way.
-
Could you PLEASE make it so that when I type SG into the left side of the ladder that a STAGE instruction will be entered. It drives me nuts having to arrow-keys or CTRL+W to get to the right hand side of the ladder in order to put an instruction on the left...
If it is too big of a deal then I'll try to understand... :P
-
Valid gripe. Legacy issue. Try END key.
Edit: And that is on our wish list. Not sure if it will make 2.0, but let's put it this way, we are not proud of the way it works,
-
....or be like me and hold out till there's a better SFC UI! ;D
-
....or be like me and hold out till there's a better SFC UI! ;D
Have you seen the custom comm code he writes? He ain't waiting.
-
No I haven't, but I can imagine there are a lot of apps where it's worth it!
-
No I haven't, but I can imagine there are a lot of apps where it's worth it!
In spite of how bad it is, about 40% of apps use it.
-
I'm a snob, what can I say? :D
-
What about adding some of the IoT protocols like MQTT or the like?
-
What about adding some of the IoT protocols like MQTT or the like?
In time, sure. Pretty covered up now with the new platform, but once it's done we'll be looking at other things to do.
-
The ability to set the priority flag on the email to high importance
I could have used this today, so here is my vote.
-
The ability to set the priority flag on the email to high importance
I could have used this today, so here is my vote.
Somehow I'm doubting thinking a feature that only gets requested every 8 1/2 years may not get too high a priority.
Poor pun I know, but I didn't even intend it.
;D
Grammar Edit
-
Are there good puns? :)
I didn't even see how old that post is (older than my daughter, and she's in second grade). I just searched the site for "email priority" and piggy-backed. I imagine it would take adding a checkbox that adds the priority or importance value to the email header. I know it's not difficult to implement, and must be low on the to-do list, but maybe my mention of it will be the last straw. Or maybe it was your mention of it that was the last straw. Hmmm...
-
PLCNUT just was reading through this thread. Yea, why when I type SG for a stage, it doesn't happen? I see they are going to "fix" it. I have to always do the F7 then type in SG then select SG. So from reading the thread, that is not how it should work?
-
PLCNUT just was reading through this thread. Yea, why when I type SG for a stage, it doesn't happen? I see they are going to "fix" it. I have to always do the F7 then type in SG then select SG. So from reading the thread, that is not how it should work?
SG works fine for stages, you just have to type in on the output rail. We would like to eventually edit stages on the power rail.
-
Have you guys ever thought about making the instructions "drag and drop"?. I know lots of times I get an instruction in the wrong place on a rung and it would be nice if I could just drag it to where I want.
-
Have you guys ever thought about making the instructions "drag and drop"?. I know lots of times I get an instruction in the wrong place on a rung and it would be nice if I could just drag it to where I want.
Welcome! This would be a great feature. Surely there is a GUI programmer itching to implement this.
-
Yup, that's sweet on those environments that have it, whether for typos on original entry, or sometimes for logic changes. I also really like AB's and Siemens' address dragging. If you click on a NO contact for example, and drag it, you get the instruction and the address both. If you click on the address and drag it, it will just copy the address only to some other target location. One think I think is off with Siemens' implementation, though, is too tight adherence to Windows conventions. If you click and drag an address, without also hitting Ctrl, it will MOVE the address rather than copying it, which adheres to Windows UI conventions, but is dumb, because copying in that context is much more common than moving, and PLC guys are used to the platforms that don't do it that way, and forget to press Ctrl. ;)
-
A mouse friendly editor has been on the wish list for longer than I want to admit. The Do-more controllers themselves became so much of the focus, the long planned editor overhaul has just kept getting pushed. There are a number of slightly embarrassing things in DmD (no drag and drop, no true undo/redo, 16 character names, etc) that we really want to fix, and once BRX gets solid, we'll be able to move back to working on those things.
I think we added single instruction copy/paste in 1.4, so it's a little easier to get it moved. Ctrl^C on the instruction and Ctrl^V where you want to put it, then Delete the original.
-
Yup, that's sweet on those environments that have it, whether for typos on original entry, or sometimes for logic changes. I also really like AB's and Siemens' address dragging. If you click on a NO contact for example, and drag it, you get the instruction and the address both. If you click on the address and drag it, it will just copy the address only to some other target location. One think I think of off with Siemens' implementation, though, is too tight adherence to Windows conventions. If you click and drag an address, without also hitting Ctrl, it will MOVE the address rather than copying it, which adheres to Windows UI conventions, but is dumb, because copying in that context is much more common than moving, and PLC guys are used to the platforms that don't do it that way, and forget to press Ctrl. ;)
Fortunately there is another windows convention Ctrl-Z. :)
-
I think we added single instruction copy/paste in 1.4, so it's a little easier to get it moved. Ctrl^C on the instruction and Ctrl^V where you want to put it, then Delete the original.
Cut/copy/paste, so
Ctrl+X (cut)
Ctrl+V (paste)
does it in 1 less step.
-
I think we added single instruction copy/paste in 1.4, so it's a little easier to get it moved. Ctrl^C on the instruction and Ctrl^V where you want to put it, then Delete the original.
Cut/copy/paste, so
Ctrl+X (cut)
Ctrl+V (paste)
does it in 1 less step.
Well, duh...
-
...Siemens' implementation, though, is too tight adherence to Windows conventions. If you click and drag an address, without also hitting Ctrl, it will MOVE the address rather than copying it...
RSLogix too, if offline.
no true undo/redo
Yes please! I'm still scared of what's there now because I have no idea what it will do.
-
Yes please! I'm still scared of what's there now because I have no idea what it will do.
I'm in the same boat :)
-
no true undo/redo
Yes please! I'm still scared of what's there now because I have no idea what it will do.
I'm in the same boat :)
I'm not sure I understand this. What specifically are you scared of? You can cancel a rung edit, you can use the roll-back facility to move back prior to the edits, and DmD creates automatic backups, beyond what you might be doing yourself. The only thing undo/redo would be doing is allowing you to rewind ladder edit states within a view.
-
This feels like trying to explain what kind of monster I am afraid might be under the bed.
I just tried again and still am not comfortable with it. It feels cryptic and the whole "close what I am doing and reload a previous state", especially when I am not sure what exactly that state is, feels like signing a pact with...
Usually a quick Ctrl-Z to fix the blunder I just made is my goto. Especially with troubleshooting/debugging something where I have probably bounced around trying things means I do not want to leap back in time, I want to take small backsteps through the edits. If I undo one too many, I at least know pretty much where it was (and redo is handy there.)
I am not very methodical in how I think - I always turned in my outlines after the essay was finished in school. It's pretty much too late to change now, nor do I particularly want to.
-
This feels like trying to explain what kind of monster I am afraid might be under the bed.
I just tried again and still am not comfortable with it. It feels cryptic and the whole "close what I am doing and reload a previous state", especially when I am not sure what exactly that state is, feels like signing a pact with...
Usually a quick Ctrl-Z to fix the blunder I just made is my goto. Especially with troubleshooting/debugging something where I have probably bounced around trying things means I do not want to leap back in time, I want to take small backsteps through the edits. If I undo one too many, I at least know pretty much where it was (and redo is handy there.)
I am not very methodical in how I think - I always turned in my outlines after the essay was finished in school. It's pretty much too late to change now, nor do I particularly want to.
Fair enough.
Had DirectSoft been written in the last 10 years, I'm sure the underlying design would be a bit different, but the foundation was laid in 1992. While vast swaths of it have been re-written, in some cases more than once, the fundamental approaching to editing, storing, compiling, etc, hasn't changed that much over the years. It is very much a desire of ours to finally bite the bullet and recreate the editor with the mousing and edit journaling features everyone wants, but we simply haven't had the horses or time to do so. BRX was *huge* for us, both in how heavy a lift it was and hopefully in how it enables the next wave of growth that will allow us to take on some of these issues.
-
Regarding the undo feature: Many times I am only wanting to undo something minor, but when I hit CTRL Z I get the popup with a list of different backups to revert to, but I don't know how much is actually going to be undone, and so I opt to manually undo it.
-
What about adding some of the IoT protocols like MQTT or the like?
In time, sure. Pretty covered up now with the new platform, but once it's done we'll be looking at other things to do.
I just figured I throw this back out into the mix now that the new platform has been released. (It would be nice to have on the no-IO units for sure)
-
What about adding some of the IoT protocols like MQTT or the like?
In time, sure. Pretty covered up now with the new platform, but once it's done we'll be looking at other things to do.
I just figured I throw this back out into the mix now that the new platform has been released. (It would be nice to have on the no-IO units for sure)
Was just looking into this. Seems pretty easy. How common is this now?
-
IBM claims "MQTT is the de-facto standard and ISO standard for messaging protocols"
Using the opensource mosquitto MQTT broker, and some javascript it is very easy to create nice web based dashboards.
Also, every IOT dashboard provider online expects you to send messages using MQTT in either plain text or JSON format.
-
IBM claims "MQTT is the de-facto standard and ISO standard for messaging protocols"
Using the opensource mosquitto MQTT broker, and some javascript it is very easy to create nice web based dashboards.
Also, every IOT dashboard provider online expects you to send messages using MQTT in either plain text or JSON format.
Cool. It's an awesome standard developed by some really smart people.
I'm sympathetic and we are very interested in pursuing this, but, I want to make sure that there is something specific to talk to if we add it. So my question remains: From a device support standpoint, with specific emphasis on how a PLC would use it, how common is it and how much stuff is deployed on or near the factory floor that supports MQTT?
Host has invested a tremendous amount of engineering resources pursuing stuff in markets that never materialized, and that's not a great way to build a business. We are starting to get requests for it, I just want to make sure we don't fall into the same trap again.
Another question: The client side is pretty obvious, but what form does the broker normally take and what would you see acting as a broker in a factory environment?
-
Another question: The client side is pretty obvious, but what form does the broker normally take and what would you see acting as a broker in a factory environment?
Ignition has MQTT modules developed by Cirrus Link. Not sure how much usage they're getting, but I've seen various ads pushing MQTT/IIOT functionality. I've also seen articles/blog posts/etc. that sound like some of the other players are working on solutions in this sector.
-
I see the obvious benefit of the PLC being able to send and receive data from systems upstream, and I think that by itself may be enough to justify development. When I hear the word 'sensor', however, my mind immediately goes to control, and I start seeing the PLC as a subscriber of lower level data. That may prove to be a valid use over time, but my guess is that MQTT would be more useful reaching up the chain, rather than side-to-side or down.
-
Here are some of my thoughts.
There seems to be a push in the industrial arena talking about IIOT.
The ability for a remote PLC to push metrics to a IOT dashboard for anywhere access from any device with a web browser.
Many of these dashboards/brokers are Free/Low cost.
You can also setup a local broker for free! https://mosquitto.org/
Local dashboards for shop floor.
Any device that can display a web browser can be used as a billboard.
I really like MQTT support because it is open source. It makes is really easy to build solutions that do not cost an arm and a leg.
-
Reading more. Liking it. PLC side is simple. Also seeing a possible factory floor friendly broker appliance with dual Ethernet...one up and one down...to keep internal and external networks segregated. Lots of potential there for a product that brings this to the floor without requiring IT expertise, as well as providing MQTT access to things which don't have it.
-
... Also seeing a possible factory floor friendly broker appliance with dual Ethernet...
There are a number of open source linux systems (OpenWRT, LEDE) that have been in the market for quite some time and have strong communities and a huge package management system.
I am currently running one of these with OpenWRT on a GL-inet router https://www.gl-inet.com/product/gl-ar300m/ (https://www.gl-inet.com/product/gl-ar300m/) as a MQTT broker, and will be starting on a perl modbus module to basically do that same thing.
Obviously you at Host could do a much better job at this, I only mention this as a quick and easy way to setup a proof of concept or prototype.
-
Obviously you at Host could do a much better job at this, I only mention this as a quick and easy way to setup a proof of concept or prototype.
I wouldn't say better, I would say more appropriate to the target venue and more specific to the need.
We were kicking around the idea of adding a PLC programming remote access portal too. Basically from DmD you would build the comm link to target the portal, and it would translate from a secure TCP-based connection to the unsecured UDP-based world of our products. I don't think it would be too hard to do and would be a very clean solution to a problem that people fight with constantly, but there are concerns of liability due to security exposure. I share the concern, but it bugs me to no end that I can't make life better for 99.99% of my customers because of the 0.01% chance of trouble...while I know that folks are taking far bigger risks because of the lack of good solutions.
-
Obviously you at Host could do a much better job at this, I only mention this as a quick and easy way to setup a proof of concept or prototype.
I wouldn't say better, I would say more appropriate to the target venue and more specific to the need.
We were kicking around the idea of adding a PLC programming remote access portal too. Basically from DmD you would build the comm link to target the portal, and it would translate from a secure TCP-based connection to the unsecured UDP-based world of our products. I don't think it would be too hard to do and would be a very clean solution to a problem that people fight with constantly, but there are concerns of liability due to security exposure. I share the concern, but it bugs me to no end that I can't make life better for 99.99% of my customers because of the 0.01% chance of trouble...while I know that folks are taking far bigger risks because of the lack of good solutions.
This is really interesting, I currently use eWON devices to have remote reprogramming and remote control access to the machines.
In such a "portal", would there be the ability to pull logs from the DoMore? What about other devices like the cMore?
-
Will the new PLC have support for DNP3 Master / Slave?
Sorry, no. I'm not familiar with DNP3. What types of applications would a PLC be useful as a DNP3 Master? What types of applications would it be useful as a DNP3 Slave?
What is the physical layer for DNP3? Is it RS-232? 422? 485? Ethernet?
I realize that this is a super old post Franji1 but I'm bumping it due to the recent realization that DNP3 is the go-to in the Water Treatment and Power Distribution industries. This is simply due to the fact that it can buffer in the case of flaky Ethernet (radio) links. Has there been any development happening in this area since '09?
-
I would really like to see some enhancements to Stage. For instance:
* I can't renumber blocks of stages in Documentation Editor using Ctrl R like I can with X,Y,C,V, etc elements. It's really painful to renumber stages one at a time.
* While in the Documentation Editor, stages are not listed numerically, they'll be in an alphabetical order such as S0, S10, S100, S11, S30 then S4, etc.
* I can't enable or disable a stage while in Data View.
* I can't copy stages in Data View using Ctrl Enter, so again you have to type in the name of every stage value that you want.
-
* I can't renumber blocks of stages in Documentation Editor using Ctrl R like I can with X,Y,C,V, etc elements. It's really painful to renumber stages one at a time.
Do-more is far more complex than DL, and creating stages as global block memory was going to create a level of complexity that was unmanageable. Making stages struct fields solved many problems, but introduced a few others. We do have plans for a Stage Manager whose sole purpose is renumbering and reordering stages. I think this issue will go away when we add that.
* While in the Documentation Editor, stages are not listed numerically, they'll be in an alphabetical order such as S0, S10, S100, S11, S30 then S4, etc.
That's a known issue and should be fixed in 2.1.
* I can't enable or disable a stage while in Data View.
We can look at adding a stage set/reset option to the Data View. It's not a memory operation per se (which is why it isn't there), but I guess from a user's perspective that's really academic.
It is possible to do it now from the Project Browser. Right click on the stage, select Debug Code-Block, and then Enable/Disable Stage. I'm thinking we have a case to add it to the right-click menu on the stage itself.
* I can't copy stages in Data View using Ctrl Enter, so again you have to type in the name of every stage value that you want.
That's there. Struct fields are iterated with Ctrl-Shift-Enter.
-
* I can't copy stages in Data View using Ctrl Enter, so again you have to type in the name of every stage value that you want.
Use Ctrl+Shift+Enter to advance to the next field, which in this case is the next Stage bit
-
Would it be possible to directly communicate to an SQL server?
TDS protocol is what would be needed, then add some instructions for setup to do the login and data transactions.
This would eliminate the need for a network attached server and associated software to bridge the PLC/PC gap.
With the awesome abilities of the Do-more, this would open some new doors.
-
Would it be possible to directly communicate to an SQL server?
TDS protocol is what would be needed, then add some instructions for setup to do the login and data transactions.
This would eliminate the need for a network attached server and associated software to bridge the PLC/PC gap.
With the awesome abilities of the Do-more, this would open some new doors.
Users have already rolled their own through HTTP, although we might consider building it in once we get further down the BRX road. We're pretty covered up with BRX development for a while, but we definitely want to add protocols once we get some critical things complete.
-
According to Microsoft,the HTTP endpoints are not supported after version 2012 of SQL Server.
We are running 2014 company wide.
-
Just got the BRX and Love it, but I have a suggestion for a new string command
MStoHMS Would convert the Microseconds on a on a timer structure to a sting as "Hours:Minutes:Seconds", right now I just do a bunch of math and then convert it, would be nice to just have one command to do it.
-
Just got the BRX and Love it, but I have a suggestion for a new string command
MStoHMS Would convert the Microseconds on a on a timer structure to a sting as "Hours:Minutes:Seconds", right now I just do a bunch of math and then convert it, would be nice to just have one command to do it.
It's kinda already there. FmtTmr() will convert a ms timer accumulator into a smart time value. It isn't exactly what you want, but it's close.
-
Just got the BRX and Love it, but I have a suggestion for a new string command
MStoHMS Would convert the Microseconds on a on a timer structure to a sting as "Hours:Minutes:Seconds", right now I just do a bunch of math and then convert it, would be nice to just have one command to do it.
Already there. Look at FmtTMR() function in the String Scripting Language Reference Help topic DmD0168
Usage: FmtTMR(value element, smart or full (optional, smart default), sec or tenths or hundredths or thousandths (optional, thousandths default))
-
Now I feel Dumb, Ill have a look at it.
-
Now I feel Dumb, Ill have a look at it.
No need to feel dumb. I cannot tell you the number of times I have forgotten what's in Do-more...and I'm on the development team.
-
Was just looking into this. Seems pretty easy. How common is this now?
I see MQTT has been discussed fairly recently. Has there been any additional developments?
I came here specifically to see if Host was working on MQTT for their PLCs. I see that AutomationDirect/Host Engineerings knock-off competitor in Iowa has a PLC that supports MQTT, at least Publish only.
I think MQTT has become somewhat of a "defacto" standard for non-real time data transfer between devices and information systems across the web. Keep in mind that some applications are not even using the PLC for control but for monitoring. In my experience, the "IoT" world has little to offer in the way of actual hardware for industrial interfacing (4-20ma, high voltage I/O, etc.). Even finding platforms that support 24V I/O can be challenging. Security is always an issue, especially for inbound data. However, I think it limits the usefulness by having only Publish capability. (Although Publish is better than nothing.) I think Subscribe should be made available as well but with all the necessary warnings about security. MQTT can be used over TLS and there is some provision for username/password to access a broker. In the end, let the developer determine if inbound data is enabled or not.
My use case would be primarily monitoring of remote systems with very limited control. Probably more filtering and scaling of inputs than any hard control. The remote systems would be connected using cellular gateways with centralized cloud server to handle alarm SMS/Email messaging and hosting monitoring dashboards.
My only other wish would be a "C" style programing language instead of ladder logic. I know its probably unlikely but one can dream, can't they? ;)
-
I see MQTT has been discussed fairly recently. Has there been any additional developments?
It is a high priority. It isn't developed yet, but our goal is to support it for DmD 2.2. Most of our software releases at this point are driven by hardware schedules, but the major DmD 2.2 features that we want is TLS email support and MQTT. TLS email is basically complete, and we hope to start MQTT soon, but there is still considerable H/W work ongoing. Our goal is to support both publish and subscribe.
TLS is *heavy*. We are supporting it for email (at great pain) but are not planning to do so for MQTT in the controller. We are kicking around the idea of doing an enhanced ECOM module that would add some TLS features, including MQTT and an encrypted programming connection.
My only other wish would be a "C" style programing language instead of ladder logic. I know its probably unlikely but one can dream, can't they? ;)
Yeah...probably not. We have kicked around the idea of adding something like LUA, but there are real concerns that support would be a nightmare.
-
TLS is *heavy*. We are supporting it for email (at great pain) but are not planning to do so for MQTT in the controller. We are kicking around the idea of doing an enhanced ECOM module that would add some TLS features, including MQTT and an encrypted programming connection.
Yes, I agree TLS is pretty "heavy". We certainly don't want it affecting the real-time performance of the control loop. I think standard MQTT will be a good start. A broker on the network edge can handle the TLS/SSL to an external broker if absolutely necessary.
I like the idea of an enhanced ECOM. Maybe a full Linux machine? There are many SiP options available now that would allow it to fit even in the D05/06 chassis. Check out http://tinyurl.com/y957dm3k, full 1Ghz TI Sitara Cortex-A8,512MB RAM, 2-200Mhz 32bit RISC processors in a 21mm x 21mm BGA package. It would certainly handle all the TLS/SSL needs and much more. (I would really like to see a Linux CPU but now I know I am really dreaming. ;) ::) ;D Which BTW I still have over 20 WINPLC's STILL running. )
Thanks for all the great products! I will keep my eye out for upcoming software releases.
-
We certainly don't want it affecting the real-time performance of the control loop.
I won't go into the magic under the covers, but it does work with a minimum bump. The TLS handshake isn't going to be fast by any measurement, but I'm fine with that for sporadic emails from a PLC. Not so much for something like MQTT.
Not sure what the platform would be for an advanced ECOM, but I would certainly expect it to be running some form of OS or RTOS...TBD.
I love the idea of having two Ethernet ports...one external and one internal...to be able to do things like run a standard MQTT broker to the internal port, and then it do TLS-based client to the external port. I could see it becoming a great tool to bridge the factory to the outside world. Not a full VPN, but a tool to provide a few specific functions helpful to PLC customers.
-
I would like to see a "Keep Window on Top" feature implemented. Where you could keep the simulator and/or the Data window open on top of the Ladder window. I use this feature frequently with RSLogix. It's a great tool, especially while working online.
-
Being able to have nicknames longer than 16 characters would be a plus.
I find myself abbreviating a lot and then wondering what I meant.....
-
Being able to have nicknames longer than 16 characters would be a plus.
I find myself abbreviating a lot and then wondering what I meant.....
Been on the list forever, but we do expect this one to get some effort in the next year or so.
-
If its not too much trouble, When creating a memory block, I'd like to be able to have numbers in the block name(Bin1Data).
-
If its not too much trouble, When creating a memory block, I'd like to be able to have numbers in the block name(Bin1Data).
It's technically possible to have a number anywhere but the first or last character, but due to the complexities of parsing, we've chosen not to go there. We are going to be making significant improvements to our entire memory structure over the next several releases, so we might be able to add more flexibility.
-
Any plans to make this work(Allow a pointer in the Set If Equal destination.)? or is it not doable for other reasons?
-
Any plans to make this work(Allow a pointer in the Set If Equal destination.)? or is it not doable for other reasons?
hmmm... Not sure why that is not allowed. Will look into that.
-
hmmm... Not sure why that is not allowed. Will look into that.
PLC instruction is correctly handling. Simple DmD change.
-
PLC instruction is correctly handling. Simple DmD change.
Don't understand that Bob, could you word it differently?
-
Don't understand that Bob, could you word it differently?
The PLC firmware supports array elements for those 3 "if" parameters. However, the Do-more Designer (DmD) software placed the restriction of DISallowing arrays. Hence, it is a simple tweak to DmD to let STRCMP support bit arrays for those 3 "if" paramters.
-
Thanks franji.
-
Fixed. It will be in the next release of DmD (Do-more Designer ;D)
-
Don't understand that Bob, could you word it differently?
I was confirming to Franj that the PLC is correctly implementing full parameter support that would allow the array references you tried to use. In some cases we don't.
-
Simulator Improvements for Analogs
16, 14 or 12-bit option for Input and Output. To more closely represent real world devices (modules)
-
Simulator Improvements for Analogs
16, 14 or 12-bit option for Input and Output. To more closely represent real world devices (modules)
The only thing it would really affect would be the input slider and output bar. Absent configuration, you could throw SCALE boxes on them.
-
The only thing it would really affect would be the input slider and output bar. Absent configuration, you could throw SCALE boxes on them.
Essentially what was done (16-bit example):
DST29=1
MATH: (TOREAL(WX0)/4095)*65535
-
As a user, I would like to be able to send software feedback via Do-more designer, so I do not have to use a forum to provide feedback. This might make receiving feedback a little easier, would allow you to filter automatically if you had drop downs to determine in what areas the most requests come from. Perhaps in the Help -> Customer Feedback -> Send user requests or something similar. Thanks
-
As a user, I would like to be able to send software feedback via Do-more designer, so I do not have to use a forum to provide feedback. This might make receiving feedback a little easier, would allow you to filter automatically if you had drop downs to determine in what areas the most requests come from. Perhaps in the Help -> Customer Feedback -> Send user requests or something similar. Thanks
You don't have to use the forum. We get feedback all the time through the support email. We just ask on the forum because it gives us a chance to discuss and elaborate as appropriate.
-
As a user, when logging data via the FILELOG instruction for example, I would like to see the time in excel readable format that also displays milliseconds, so that when logging data in less than one second intervals I do not get multiple data points for the same time as it makes it difficult to plot offline.
Format would be hh:mm:ss.000, where 000 is in milliseconds. For example: 01:23:45.678 stands for one hour, 23 minutes, 45 seconds and 678 milliseconds.
The example below shows the output when logging at 100 millisecond intervals (10 data points for the same one second). Thanks for your consideration!
TimeStamp(sec,local) R0
2021/7/23 13:59:51 1.139
2021/7/23 13:59:51 0.5029
2021/7/23 13:59:51 0.2795
2021/7/23 13:59:51 0.1685
2021/7/23 13:59:51 0.1343
2021/7/23 13:59:51 0.1221
2021/7/23 13:59:51 0.1294
2021/7/23 13:59:52 0.1465
2021/7/23 13:59:52 0.1489
2021/7/23 13:59:52 0.1636
2021/7/23 13:59:52 0.166
2021/7/23 13:59:52 0.1648
2021/7/23 13:59:52 0.1636
2021/7/23 13:59:52 0.1526
2021/7/23 13:59:52 0.1624
2021/7/23 13:59:52 0.1624
2021/7/23 13:59:52 0.1636
2021/7/23 13:59:53 0.1648
-
EDIT: Didnt realize this was DirectLogic, so will duplicate in Domore forum to make sure it is seen.
One Shot / Pulse Timer
Realized there isn't really one built in, and while it is not necessarily difficult to make it may provide a shortcut and even help with people coming from other platforms (siemens).
Created a simple Subroutine and Structure to make the code reusable, using the CALL to copy the structures In & Out. Not as efficient (scan time wise) I am sure but makes it easier to track/debug: https://forum.hosteng.com/index.php?topic=3486.0 (https://forum.hosteng.com/index.php?topic=3486.0)
-
I need a triggerable high speed analog input card. So I can do power waveform feature extraction and fast real time control.
Like a DSP more or less.
-
I need a triggerable high speed analog input card. So I can do power waveform feature extraction and fast real time control.
Like a DSP more or less.
We are actually thinking about something like this. We are building very high speed analog for a custom application, and have been considering how we could use the hardware as standard product. First thought is to allow selection(s) of a) sample rate, b) bit depth, and c) data stability. Basically you pick any two, and we'll tell you what the third is. To support speeds faster than the PLC scan, we'd make the module capable of interrupting the PLC on new samples. So for apps like yours, you'd pick the sample rate you need and the minimum number of bits that would do the job, and we'll tell you how sloppy your samples will be. Haven't yet worked out how it would get enabled (for a capture cycle), but that shouldn't be a too difficult.
Not applicable to your app, but the opposite end would be supported too. You need 32 super stable bits? Cool...might take 10 seconds per sample, but it could do it. That side isn't too bad now, since you can oversample existing analog, but having the module manage it is nice.
We were a little concerned that a module like this might be a solution in search of a problem, so it's good to hear a customer request it.
-
I think there might be [rare] times I could use this too.
-
Triggerable analog sampling:
To focus this effort, think about sampling a waveform on multiple channels with as little skew as possible. I would like to be able to trigger the conversion with program logic or an interrupt.
With the right capabilities, I could do 3 phase power monitoring with the BX, recording three current and three voltage channels. For some control requirements, reading power using communications from a power meter (which also has its own built-in latency) is just too slow. Getting power measurements every cycle would be a game changer.
This is stuff I've done since the 80's using microcontrollers, it would be nice for PLCs to catch up, even though I don't necessarily want the power/complexity of a DSP or a FPGA.
Bill Thomson
-
1. USB memory stick drive for PLC program save and downloads.
I second (30th?) a USB port that can be used for file transfer.
Our end users want to save log files, process recipes, etc, and load recipes from another machine. I am asked for this on every system we design, and we are newly using BRX and finding that our userbase is balking at SD card Use. The ability to have OnBoard USB like Proface, for example, is ideal. Even if we could FTP the files over to the CMore HMI and use its USB port, that would be good. We are working on our own solution, but built-in is best.