My last post left off just short of how the script files were implemented and/or tied together to complete the system… so here we go.

Links to previous parts of this series:

• Industrial Raspberry Pi Project, Part 1

• Industrial Raspberry Pi Project, Part 2

• Industrial Raspberry Pi Project, Part 3

With separate script files all able to run the individual components (including the two fans), it was relatively easy to merge them all into one main script file.  But the system needed more functionality than just the internal components.

The scope of this project called for data not only saved to the attached USB drive (easily configured to a network drive if desired), but also to communicate specific data to a web-based dashboard (used Adafruit IO) and locally to an industrial controller (PLC) or display via Modbus TCP.

Modbus is a serial fieldbus communications protocol. It is a master/Slave protocol that can be handled by wiring from device to device with the typical transmit and receive wiring of a 9-pin d-sub connector or sometimes with two-wires daisy-chained between screw terminals.

For this application, and a growing use of it these days, it can be implemented over ethernet.

With industrial equipment made by OEMs such as Keyence (i.e., camera controllers) and Mitsubishi (PLCs, VFDs, and HMIs), it can be referred to as ModTCP or Modbus TCP.

One author refers to it as the “grandfather of modern fieldbus,” and states that it is still doing the job after four decades.

With Modbus, you read and write from holding registers. These registers are then transmitted internally to tags or data registers determined by the manufacturer but are still within industry standards.

For the two prototypes discussed here, there are pyModbusTCP API and Modbusclient declarations that are declared in the setup portion of the script.

From there, it is some simple connection open and monitoring commands in partnership with the connection write or read commands.

The final script configuration utilized 4 script files (Modbus TCP used in Comms script, Data Logging, System Operations, and a MQTT connection script for the URL dashboard connection) that all started on power up.

I decided it was best to break up the main script file as well as the others for them to operate asynchronously.

I utilized the autostart file setup (/home/pi/.config/autostart) I found while researching the best way to start up a script automatically on Pi boot up.

It worked just as I had hoped and would be easily setup even by the greenest of coders.

With an additional fan and some vent holes made in the enclosure necessary for needed air flow and reducing backpressure, both prototype systems were able to run for many hours (full workdays on several instances) at my desk.

The field test went smoothly with both prototypes for a good three-hour run.  Then a final overnight test was run with the #1 prototype.

When analyzing the captured data file, it went very smooth.  The ambient temperature was even low enough on the factory floor to keep the processor temp down and the fans only turned on and off a couple times to start. They then remained off for the remainder of the trial (22 hours).

Creating the CSV file (for data logging) was just as simple to implement as other components of this system.

With some simple examples and tutorials online and even YouTube, the format was somewhat simple and straightforward.

###  Print to a CSV for recording data or system info  ###

file = open(“/media/pi/USB_Drive_Name/file location if desired/filename.csv”, “a”)

file.write(“Message to write to file”+”\n”)  #file write of message plus a carriage return

file.flush() #clear writing cache

file.close() #close file

The “a” option at the end of the command line specifies the file will be opened and entries will be appended at the end of the file.  The file write would look a little different depending on if writing to the data log file or the system message file (as is shown here).

If a new file is needed or the datafile is a single line that gets written over, the “a” would change to a “w”.  This same setup was used for the system log, data logging, and output to the Modbus TCP script.

The main file would write (and overwrite) a single line in the modbus.csv file. The script would then read that one line and output the corresponding values out to the Modbus registers.

Conclusion

This project was fun as well as challenging to work through to completion. Watching the two prototypes simultaneously communicate over VNC to a laptop, Wi-Fi to the dashboard, and over Modbus TCP to a Mitsubishi HMI was very rewarding.

I can obviously never include every little detail in a writeup like this, so feel free to post questions or email me ( cntrlengr at hotmail dot com ) and I will do my best to answer the questions or help in any way I can.

Don’t be discouraged to try your own Raspberry Pi industrial project. I feel it has a great niche in respect to some R&D prototyping, automating a single process, or even a complete shop floor.  There are so many examples of currently running projects but go ahead and try something new!

Thanks for reading this short series I created during and after my Senior Design project made as part of completing my B.Sc. in EET at Purdue Fort Wayne (completed as of May 12th, 2021).

I would like to say a special thanks to Fort Wayne Metals for making it possible to return to school, for some of the funding of the project, and allowing me to run the prototypes on the shop floor to help monitor an existing process.

#DONEIN21

Written by Paul Hunt
Senior Automation Engineer and Freelance Writer

Have a question? Join our community of pros to take part in the discussion! You'll also find all of our automation courses at TheAutomationSchool.com.

Sponsor and Advertise: Get your product or service in front of our 75K followers while also supporting independent automation journalism by sponsoring or advertising with us! Learn more in our Media Guide here, or contact us using this form.

• Author
• Recent Posts

Shawn Tierney

I'm a lifelong Technology Enthusiast who began programing in the early 80's on the Apple II and VIC-20 personal computers. After earning a degree in Electronics, I worked as a Certified Controls and Information Automation Specialist for 25 years before leaving to become a full time Industrial Automation instructor and mentor at TheAutomationSchool, as well as publishing industry interviews, news, and product how-to’s at TheAutomationBlog.com. If you're interested in my training, mentoring, or becoming a sponsor, please schedule a teams meeting with me via https://calendly.com/shawntierney/business-meeting

Latest posts by Shawn Tierney (see all)

• First Look: Siemens S7-1200 G2 – Unbox, Wire, Program (S2E13) - April 17, 2025
• MaintainX: Prevent Unplanned Downtime (P236) - April 9, 2025
• First Time Using Ignition: Tags and Views (P235) - March 24, 2025

 

Up to this point I have a complete system… almost. The enclosure (still with a few revisions to go) is essentially complete, and everything has been mounted and fits.

However, the system still needs code to function. So now I dive in headfirst with a system I have never used before and code I do not know.

Links to previous parts of this series:

• Industrial Raspberry Pi Project, Part 1

• Industrial Raspberry Pi Project, Part 2

I spent quite a bit of time searching the web for various help topics and forum posts to help with various aspects of troubleshooting as I got on with the setup and power up. This is definitely a good use of the web as a tool for research and support.

Turns out that I am NOT the first noob to try and set up a Raspberry Pi with an LCD or any of the other components. There are also plenty of experienced users that are willing to help in forums or even by email.

I started with the Raspberry Pi and the PiTFT from Adafruit. There were plenty of helpful tips out there that can get anyone to the point that it will power up and display the same as the Pi does by default out the HDMI port when first powered up.

This may take some trial and error with the editing of a couple config files, but not something too difficult to do with some careful following of a web tutorial or two.

The functioning LCD got me excited since the touch and both the display options were all nice additions, essential in my opinion, to this system.

If I could do it again, I would go with one a larger screen (LCD used is only a 2.8”).  Other larger options looked to interface the same.

I feel that the use of references and tutorials is a crucial aspect of any project you undertake like this. The less familiar you are with components or the combination of, the more imperative it is to have resources (web searching, journals, or specific websites) that you can refer to for ideas to help with what you want to achieve.

Using the standard Python editor (Thonny) that came included on the OS worked perfectly for me. The only thing to keep an eye on when doing this is the version of Python being used.

I did have to be sure I was editing and running on a specific version that worked with all the code examples I was using.

One instance was with the Scipy code being used for the thermal sensor. I ran into an issue when compiling with a fault for the module not being found.

I then ran a command line using a direct reference to the Python version (3) I found on a forum:

sudo apt-get install -y python3-scipy python3-pygame

That seemed to not only go through a complete install but also ran some additional items.  It then worked perfectly!

To save this image as a file that could be viewed later, I had to do a screenshot. This was done easily by using a specific Raspberry Pi API.

Declaration:

#use pyautogui for screenshot

import pyautogui #added for screenshot function

Use in script:

screenshot = pyautogui.screenshot()

screenshot.save(“screen.png”)

Now with the thermal sensor working, I can come back to the full implementation later.  For now, it was time to move on to the function of the camera.

Since the Pi is set up and all ready to take a camera so easily, this was not too difficult. But for a noob, it was just a matter of following the code and setting things in the code that may be needed for the specific application.

For my application this involved some research onto some of the built-in parameters like rotate, setting the size of the image, and naming of the output file.

At the start of the code, I used the following to initiate the use of the camera…

import picamera

camera = picamera.PiCamera()

# ROTATE

#camera.vflip = True #can do horizontal flip too

camera.rotation=90

This line then is used in the code to do the capture, size it, and set the name for the output file.

camera.capture(‘image.jpg’, resize=(320, 240))

With the two imaging components functional, time to get started on the ambient sensor.  This took a little more than the other sensors to implement.

I had to select a specific input point on the Pi as well as soldering a resistor into the circuit.  On top of that, in the end, I had to use another 5 Vdc source for the sensor instead of an open and unused 3 Vdc.

The implementation of the sensor still had issues. I got data back from the sensor easily enough but found that it was not 100% consistent.

Also, the background process was causing issues when the script was run, stopped, and started again.

The fix for this took some time and lots of web crawling to figure out. The consistency issue had a work-around as well in the form of error trapping in the code.

In this project, I chose to simply write a line of text out to a log file that also monitored communications errors and timestamps of power cycling.

To get around the issue with the background process (libgpiod_pulsein), at each power-up I programmed a check to see if it was running.  If it was, I killed it so the DHT sensor could then initiate properly.

I tried one suggested approach of killing the process using the process ID.  This was not working as the ID was different in every instance.

I then chose to use the libgpiod_pulsein by name.  This was easy to monitor using the “lxtask” from the command prompt.  This pops up an app similar to Windows Task Manager.

##########  DHT22 Sensor Process Kill if active  ###################

def check_kill_process(pstring):

  for line in os.popen(“ps ax | grep ” + pstring + ” | grep -v grep”):

    fields = line.split()

    pid = fields[0]

    os.kill(int(pid), signal.SIGKILL)

check_kill_process(‘libgpiod_pulsein’)

# Initial the dht device, with data pin connected to:

dhtDevice = adafruit_dht.DHT22(board.D4)

##################################################

Sample of captured data from DHT22 Sensor:

Now I was able to get values from the sensor and not shut down, restart, or fault out if issues arose with the connection.  Time to move on.

One other issue the system had that was important to correct was the seemingly unstable and continuously dropping Wi-Fi.

There are a few things I found to try on the web that include setting the country code in the OS settings. This seemed to help at first.

The main stable fix came when I replaced the 24 Vdc to 5 Vdc regulator. The output when the input was 24 Vdc was only 4.6 Vdc.

This was affecting performance as well as posting a warning on the display for low voltage.  This was fixed with a variable buck-boost power supply.

This component was twice the size as the original regulator but luckily it fit. The power supply was purchased from DFRobot and allowed for 3.3-28 Vdc in with 3-24 Vdc out at 25 Watts.

At 5 (or 5.1) Vdc out, this gave me plenty of current supply (5A) for the needed 3A the system required. When using one of these power supplies, be sure to check the output voltage first… I found out the hard way that the output was set to the max (24 Vdc) by default.

The Pi DID NOT like this.

One more item I tried with the Wi-Fi that the 3B+ Pi did not like was a USB Wi-Fi antenna.

This was apparently too much for the Pi to supply with the already connected LCD, camera, thermal sensor, and ambient sensor.  It seems that the internal power supply bit the dust on that one.

Come back for Part IV (the final one) that will discuss the various script files and implementation.

Written by Paul Hunt
Senior Automation Engineer and Freelance Writer

Have a question? Join our community of pros to take part in the discussion! You'll also find all of our automation courses at TheAutomationSchool.com.

Sponsor and Advertise: Get your product or service in front of our 75K followers while also supporting independent automation journalism by sponsoring or advertising with us! Learn more in our Media Guide here, or contact us using this form.

• Author
• Recent Posts

Shawn Tierney

I'm a lifelong Technology Enthusiast who began programing in the early 80's on the Apple II and VIC-20 personal computers. After earning a degree in Electronics, I worked as a Certified Controls and Information Automation Specialist for 25 years before leaving to become a full time Industrial Automation instructor and mentor at TheAutomationSchool, as well as publishing industry interviews, news, and product how-to’s at TheAutomationBlog.com. If you're interested in my training, mentoring, or becoming a sponsor, please schedule a teams meeting with me via https://calendly.com/shawntierney/business-meeting

Latest posts by Shawn Tierney (see all)

• First Look: Siemens S7-1200 G2 – Unbox, Wire, Program (S2E13) - April 17, 2025
• MaintainX: Prevent Unplanned Downtime (P236) - April 9, 2025
• First Time Using Ignition: Tags and Views (P235) - March 24, 2025