search

AccelerationConsortium / ac-training-lab

Codebase for controlling and managing the Acceleration Consortium (AC) Training Lab.
https://ac-training-lab.readthedocs.io/
MIT License
8 stars 2 forks source link

RS232 control of digital scale #20

Open sgbaird opened 2 months ago

sgbaird commented 2 months ago

Using https://www.waveshare.com/wiki/Pico-2CH-RS232 and US Solid 3kg scale

EDIT: one Pico-2CH-RS232 is available (in 3D printer room). Both the scale and the adapter that came with the RS232 module are male, so I also ordered F-F adapters. The same applies for the A&D scale.

I had trouble finding the instructions/manual for the US Solid scale online. Here is a scan of a paper copy:

uss-dbs-series-operation-manual.pdf

The directions are somewhat sparse, perhaps because continuous output is essentially the only option (compared with A&D which has a lot more functionality exposed).

Related microcourse module: https://ac-microcourses.readthedocs.io/en/latest/courses/robotics/3.2-serial-communication.html

sgbaird commented 4 days ago

Great! Could you comment briefly on how you implemented this? This relates to https://github.com/AccelerationConsortium/ac-training-lab/issues/35, which we're still not decided on in terms of a convention we want to follow.

evelynnesher commented 4 days ago

There are two global variables: connection_status and data_status which store the current MQTT connection status and the state of data reception, respectively. If you need to track other statuses, like a connection for another component or a different piece of data, you can easily add more variables and follow the same approach.

A mutex (status_lock) is used to make sure that only one part of the program can update or read the status at a time. This is important because the program has multiple threads running at once (e.g., the MQTT client handling incoming messages and the Gradio app updating the user interface). Without the mutex, both threads might try to change or read the status at the same time, which could cause errors or confusing results. The mutex ensures that these updates happen one at a time, keeping everything in sync.

The get_status function formats and returns the current status as a string while ensuring thread safety.

In the Gradio app, the status is displayed using a gr.Markdown component (status_md). This component is refreshed every second (every=1), ensuring that the status is kept up-to-date for the user without manual refreshes.

Long story short: The get_status function is called every second to retrieve the latest values for connection_status and data_status, and the Gradio UI is refreshed accordingly to show the updated status.

The current setup causes the UI to "flash" with each refresh. To fix this, I plan to adjust the implementation so that the UI only refreshes when the connection_status changes, instead of refreshing every second.

sgbaird commented 4 days ago

Nice! A simple workaround for now may be to just increase to 30 s. When a user first goes to the page is the most important time to see the status in my mind (especially if it's not connected or receiving data).