New features wanted!! Apply here!

[Barnic]

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

[BobO]

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.

[Barnic]

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


      

[Mike@Forshock]

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

[WRT2]

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.

[BobO]

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.

[Controls Guy]

I think there might be [rare] times I could use this too.

[WRT2]

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

[ZoNiE]

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.

[Watermark_JS]

The delta instruction is fantastic.  I use it all the time.  When you made it work with non-Boolean data, I started using it a lot more!  That is, until I ran into the brick wall of 32K Edge Bits. 

The delta instruction would be much more useful if:

1) some way is provided to view current (pre-download) Edge Memory usage.  This would at least allow us to see if we're getting near "the edge" of available bits.
2) additional Edge Memory could be pre-allocated as blocks in the Memory Configuration tool.

I can imagine reasons why those requests might be difficult/impossible to achieve, but it never hurts to ask, right?   

[BobO]

The delta instruction is fantastic.  I use it all the time.  When you made it work with non-Boolean data, I started using it a lot more!  That is, until I ran into the brick wall of 32K Edge Bits. 

The delta instruction would be much more useful if:

1) some way is provided to view current (pre-download) Edge Memory usage.  This would at least allow us to see if we're getting near "the edge" of available bits.
2) additional Edge Memory could be pre-allocated as blocks in the Memory Configuration tool.

I can imagine reasons why those requests might be difficult/impossible to achieve, but it never hurts to ask, right?   

When we did the initial allocation of edge bits, they were just for single edges and 32k seemed plenty. Usage got significantly expanded with new ideas. I think it would be pretty easy to double it, but more would be hard. Additional edge blocks...I'm not sure. I'd have to look at the code and ponder the implications.

[franji1]

Edge memory is more like C language's "heap" and its usage is sparse and fragmented - so "usage" does not apply (you could have just 1K of the 32K "used" and not be able to use ANY delta contacts if the single bit usage was every 32 DWORDS, e.g. E0, E32, E64, E96, etc.).

It does not get optimized - although we could definitely do that on a PROGRAM mode download.  We could definitely make that be a Project option, default would be to OPTIMIZE edge bit usage when doing PROGRAM MODE download.

That would free up some.  However, Delta contacts burn 32 contiguous edge bits on a DWORD boundary (e.g. E32:SD/R then E64:SD/R), so there must be a contiguous set of 32 bits that are unallocated on a DWORD boundary.

Even if you have no other edge bits and every edge bit is available, you can only have at most around 1000 delta contacts (32x1000 bits)

[Controls Guy]

The delta instruction is fantastic.  I use it all the time.  When you made it work with non-Boolean data, I started using it a lot more!  That is, until I ran into the brick wall of 32K Edge Bits. 

Holy cow, I never stopped to think that DLT DINT or DLT REAL would actually take edge DWORDS.   Some time back, someone suggested doing CRCs on contiguous blocks of data as a way of detecting changes.   If your data is contiguous and you can make do with knowing SOMETHING in the block changed, that might work.   OR, you could use it to isolate subsets, and keep slicing finer till you get the specific changed value(s).

Downsides would be that it would be somewhat awkward, increase scan time, and not good at isolating changes to individual values without recursion.   Also, theoretically, you can miss changes if it's just the right change.

Edit:  Just saw where franji1 said 32 bits of E-memory (tip of hat to TI) are allocated for every DLT, even individual bits.