New features wanted!! Apply here!

[bd]

The ability to label sbr constants and display the label in the gts box would be extremely helpful.


Many Thanks.

BD

[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

[franji1]

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.

[bd]

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

[polarbearchp]

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

[MichaelL65]

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?

[BobO]

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!!

[ATU]

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.

[franji1]

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?

[ATU]

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.

[franji1]

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).

[ATU]

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.

[franji1]

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!

[bnufer]

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

[JohnB]

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.