Recent Posts

1

Do-more CPUs and Do-more Designer Software / Copy and Paste from DataView

« Last post by Bolt on August 01, 2022, 11:07:07 AM »

Could we please get a simpler Copy/Paste functionality in the Data View?  Currently I have to right click the Element's Satus Column, click Copy Status to Edit, acknowledge the popup (on which I can't even read all the text) that typically pops up all the way across my other monitor, then go to the Element's Edits column, double click the cell to select all text, right click the contents, and click Copy.  When dealing with long strings, typically add in some scrolling around in the Data View to get back and forth between the large cells, and repeat as needed.  More or less reverse the process to write a value to the Element from the clipboard.  Especially when debugging JSON strings, API's, etc, it is quite inconvenient to go through all the clicking motions when it could be quite doable all from the keyboard.

It would be so much easier if I could just hit Ctrl C from the Element's status column, do whatever I need to do with it, come back, Ctrl V in the Edits column, Shift+F9, and be done with it.

Also, it would be nice if the Ctrl (Shift) Left/Right arrow functionality worked in the Edits column.  Ever tried to remove or change an email address from a string with multiple addresses, it usually requires copying to edit, expanding the Data View, expanding the columns, manually selecting the desired address, and deleting or replacing it.  Instead, if I could use Ctrl arrows to navigate through the text, it would be so much simpler.

2

Do-more CPUs and Do-more Designer Software / Re: Trend Archive Recommendation

« Last post by franji1 on July 25, 2022, 09:22:17 AM »

No.  2.9.x were primarily maintenance releases, no new features.

That one slipped through the cracks for 2.9.

3

Do-more CPUs and Do-more Designer Software / Re: Trend Archive Recommendation

« Last post by franji1 on July 24, 2022, 06:02:45 PM »

No.  2.9.x were primarily maintenance releases, no new features.

4

Do-more CPUs and Do-more Designer Software / Re: Trend Archive Recommendation

« Last post by RBPLC on July 23, 2022, 05:34:10 PM »

Did this get resolved? I exported a trend this week and just imported it and I'm still seeing R57 instead of the nickname.

5

Do-more CPUs and Do-more Designer Software / Re: MQTT Best Practices

« Last post by Bolt on July 23, 2022, 03:30:47 PM »

We will be adding a certificate database in the next release and make it available to apps that currently don't use them.

I like the sound of this.  I've tried too many cloud API type scenarios where I ran into a CA roadblock.

6

Do-more CPUs and Do-more Designer Software / Re: MQTT Best Practices

« Last post by Bolt on July 23, 2022, 03:29:08 PM »

Thank you for your perspective.  I played with it on the Sim, got comfortable, then rolled it out to a few production machines to get a feel for it with real data quantities and rates.  Now I see room to improve, and it's hard to do in production of course, because it requires a Program Mode transition.  Back to the Sim I go.

7

Do-more CPUs and Do-more Designer Software / Re: MQTT Best Practices

« Last post by BobO on July 23, 2022, 02:23:07 PM »

1. Protocol. MQTTS is an option, but where do I store the TLS certificates, etc?

Certificates are only used to verify the identity of the server and aren't required to make any TLS connection work. Currently, the only certificate BRX uses is for SMTP, and that is handled automatically when you configure the device. We will be adding a certificate database in the next release and make it available to apps that currently don't use them.

2. QoS. If I set QoS to 1, does it queue publish messages internally?  What is the capacity of this queue?

QoS1 just handshakes the publish to ensure delivery. Queuing isn't part of that, and generally doesn't need to be for publishing the "current" state of something. In general, QoS2 is for transactional publishing, where it is critical that each state change being published exactly one time. We don't support QoS2 specifically because of the issues of storing all states and guaranteeing delivery. On a PC where you have effectively infinite memory, it's no big deal, but for a small PLC, it leads to issues we didn't want to deal with. If you do want to ensure all states get published "at least once", then use a FIFO or a disk file to cache.

2a. I'm guessing that creating a FIFO sequence to queue messages to publish is best?  Any time delays needed between PUB's? Are there any caveats to using Stages with the MQTT instructions?

Yes.
No.
Not really, just be sure you understand what completion means in the context of what you are doing. Recurrent comm functions act a little different, so with stages, you need to do it as a single event and not transition until complete.

3. Session Type. Say I wanted the PLC to subscribe to a topic. If the PLC is off line for whatever reason, I would not want it to receive "old" data upon re-connecting.  Am I correct that 'Clean' would take care of this for me?  Or does QoS 0 take care of this?

Best thing to do it play with it and get comfortable with the behavior of the broker you want to use.

3a. Would it be better to create 2 MQTT devices, one for publishing, other for subscribing? That way one could queue and publish all data QoS 1, and the other would only subscribe to new data if connected?

QoS1 just handshakes and retries, while QoS0 doesn't. I don't think it changes whether something is published or not. Best thing is just to play with it.


And a caveat...I learned MQTT well enough to write the implementation...but I am absolutely not an expert and don't use it for anything other than testing. Others on here probably understand it far better than me.

8

Do-more CPUs and Do-more Designer Software / MQTT Best Practices

« Last post by Bolt on July 23, 2022, 01:40:58 PM »

I'm starting to get serious about using MQTT to communicate to the cloud from several BRX's.  I have some questions about best practices on the PLC.

1. Protocol. MQTTS is an option, but where do I store the TLS certificates, etc?

2. QoS. If I set QoS to 1, does it queue publish messages internally?  What is the capacity of this queue?
2a. I'm guessing that creating a FIFO sequence to queue messages to publish is best?  Any time delays needed between PUB's? Are there any caveats to using Stages with the MQTT instructions?

3. Session Type. Say I wanted the PLC to subscribe to a topic. If the PLC is off line for whatever reason, I would not want it to receive "old" data upon re-connecting.  Am I correct that 'Clean' would take care of this for me?  Or does QoS 0 take care of this?
3a. Would it be better to create 2 MQTT devices, one for publishing, other for subscribing? That way one could queue and publish all data QoS 1, and the other would only subscribe to new data if connected?

9

Do-more CPUs and Do-more Designer Software / Re: Secure FTP protocols

« Last post by BobO on July 19, 2022, 09:48:36 AM »

Welcome to farming.

I can only imagine. Farmers fight all the normal things plus a whole bunch more.

10

Do-more CPUs and Do-more Designer Software / Re: Secure FTP protocols

« Last post by amos on July 19, 2022, 12:25:23 AM »

Welcome to farming.