-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Vfdctl was built so that when programmatic interaction is needed with a VFD, you do not need to be aware of the specific I/O, registers or even protocol of your device in order to read or write to it. Instead, a user wanting to update a setting needs to send a command with the knowledge of the device name, the value requested and a parameter name that is consistent across every single VFD device. A user wanting the runtime telemetry just needs to specify topics they care to receive updates for in an MQTT client.
With this decoupling, there are numerous tangible benefits. While running Vfdctl, if a VFD is replaced with a different brand or changes to a different protocol it does not force your controllers, HMI or web app to be updated also. So in this scenario if the VFD is not working after you've replaced it, you can safely assume that the issue occurred while performing the setup of the new VFD because you did not have to re-download to all of your devices with potentially unintended changes. During system downtime, minimizing complexity is key to ensuring the quickest recovery.
Another advantage is that you are not tied to a single brand, make or model of VFD. For consistency, most users will opt to use the same VFD when using multiple in their system, but what if that device isn't available for another 20 weeks during a new project? What if this is a 20 year old system and that device is end of life, so there is no drop-in replacement? Imagine if we only needed to change a single config file for our Vfdctl app with the new brand and desired protocol of the new hardware and we didn't need to download to every 20 year old device on the network! This is the role that Vfdctl serves.
This page describes what’s possible to build with the different tools and APIs that are available on the platform, and how to get the access and information that you need to get started.
Across the platform, there are different controller devices capable of various protocols. This section helps to describe what you need to successfully use our APIs. In addition to the controllers below, you will need tools and cables to communicate with them such as ethernet cables, micro usb cables, power cables and a micro SD card (1GB or greater).
| Make | Model | MQTT Support | Modbus Support |
|---|---|---|---|
| Automation Direct | P1AM-100ETH w/ MKR485 | 3.1.1 | RTU |
| API | Vfdctl Version | MQTT Version Supported | Requires Cloud Connectivity? | R/W |
|---|---|---|---|---|
| Runtime telemetry | v0.1.0beta | 3.1.1 | No | Read Only |
| Settings Configuration | v0.1.0beta | 3.1.1 | No | Write |
| Last Will & Testament | v0.3.0 | 3.1.1 | No | Read Only |
- Activity and error code indication.
- Interpret patterns using the troubleshooting wiki
- Any fault will re-trigger controller initialization
- Telemetry and command handling are interrupted during recovery
- Incoming commands are possible to be queued until connected but not guaranteed
modbus.telemetry_interval_sec
- defaults to 15 seconds
modbus.serial_port.baud_rate
- Defaults to 9600/8/0/1
modbus.telemetry_registers
- Maximum of 50 monitored registers
- All configuration occurs in 'config.txt'
- Configurable source register
- Configurable source server
- Offset available for 'off by 1' corrections between brands (Configured source register + 40000 + offset)
- Maximum of 5 queued commands
- FIFO processing
- Rate limit to 1 msg/sec to prevent buildup in queue
- Queue overflow will result in dropped commands
Please make sure to bookmark the following pages, as they will provide you with important details on API outages, updates, and other news relevant to developers on the platform. Check out our releases to find the latest binaries and a history of all released binaries. Visit the Tulsa Software Repositories to find related open-source codebases. In case of any document conflicts, assume the Vfdctl readme is most accurate.
MQTT is extremely flexible and not as rigidly enforced as communications such as RPC or REST communications. This leaves lots of room for one-off implementations if systems are not intentionally designed. For our communications architecture, we have based our topic and payload structures off of the AWS best practices to ensure ultimate usability.
- Even if not using AWS IoT cloud communications, their MQTT communication patterns are widely applicable
- A good client GUI like MQTTX or MQTT Explorer makes troubleshooting your system much easier but any app supporting MQTT 3.1.1 communications will suffice
- Using a IoT Rules Engine such as Node Red, AWS IoT Core, etc is essential to utilizing data with minimal coupling and maximal scalability
For the questions not covered here or to learn what we're currently working on, visit the Tulsa Software slack channel to review topics, ask questions and learn from others.