Go Down

Topic: Arduino controlled chemistry lab build log (or building a smart hood) (Read 1 time) previous topic - next topic


I'm home now, so I can actually test this on what it was designed for.

KenF, can you elaborate on the minor hardware mods? Once I got back I was showing my brother the setup and it was still cutting out the beginning portions of some of the messages sent to the computer via serial. Again, it does not do this when viewing serial stuff in the Arduino programmer or the Visual Studio serial monitor windows.

SirJoBlack - that is an interesting idea. I can see the benefits of it, I may consider doing the same if I can't get this sorted out. Thanks for your input.


There are three methods that I know to disable the reset on com port access.

Method 1.
The simplest (and most reliable method) is to cut the "reset en" track.  On the board there are a pair of pads labeled "reset en".  Connecting them is a tiny track (so tiny, in fact, that you may not even be able to see it with your bare eyes).  If you cut this track (with a craft knife or something similar). The reset that occurs when the com port is opened will be disabled.  If you ever decide to undo this mod you simply solder another short piece of wire in place of the track you cut.  I'll attach an image to show where these pads are on the mega2560.  On the UNO the pads are slightly higher on the board (beside the 16mhz chrystal ) but still clearly marked.

Method 2
The most practical, (if you have the component available)  Simply place a 10 micro Farrad from GND to the Reset pin of the arduino.  To undo this mod you just remove it again.  This method is shown in this video .  Using an arduino to program another chip  (Sorry the vid is a bit off topic, but it's so informative, I just put it out there :)

Method 3
I have never got this one to work.  But if you place a resistor from 5v to reset (documented values vary but something like 120 ohm) It will prevent the reset occuring.  I tried various values but never got this method to work.

Whichever method you choose.  You'll find that the "upload" from the IDE will no longer work unless you hold down the reset button and release it at the appropriate time.

Yes, KENF,but these methods are "aggressive" and create problem using the IDE ... I think (when is possible) using other channels is better thus maintaining valid the development environment. But here is not the topic to discuss about this!

I think the pull-up does not work because the reset signal directly connects the reset pin to ground ( the reset is active low ) then any current is canceled.


Yes, KENF,but these methods are "aggressive" and create problem using the IDE ...
If you can press the reset button with your finger, it's not that big a deal.  If you have a mega2560 AND a suitable method to interface it to your computer then obviously such a mod is not needed. 

It's MAY also be possible to accommodate the reset in software.  It really depends what's opening the com port.

But here is not the topic to discuss about this!
If the reset is causing the OP problems, then HERE is EXACTLY the place to discuss it. 

My thought is to keep the Arduino development system running as it is and solve using what is already there! ... I think it's better to leave the serial development as it is because I have other serials!

I said that was not the right topic because it refer to the control of a chemistry lab and then the focus is how to control reactions and various equipment ... very interesting and complex.

However, it is also very interesting the possibility to modify the micro-card ... :)

KENF, I was not referring to you when I said that is not the right topic, but to my expand the discussion about the reset management!

Unfortunately, the knock on effect is that the arduino will reboot EVERY time ANY software opens that com port on your computer.  You can prevent this process occurring. using some very minor hardware mods.  Alternatively you can write your code to take it into account.
This is not exactly true though....

It all depends on how you open and manipulate the port.

One of the programming languages I use does not cause my Arduino Mega to reset and the Android App named Bluetooth Graphics does not cause it to reset either when connecting through an HC-05 that is connected to the regular Rx/ Tx pins.




This is not exactly true though....

It all depends on how you open and manipulate the port.

One of the programming languages I use does not cause my Arduino Mega to reset and the Android App named Bluetooth Graphics does not cause it to reset either when connecting through an HC-05 that is connected to the regular Rx/ Tx pins.
COM port
Which programming language you use is totally irrelevant.  If you open a connection through the USB port on an UNO or a mega, it WILL reset the board.  It's hardwired to do so.

I think there's something to observe about this. The USB hardware wiring connection is based on 4 wire: GND, Vcc, D+, D-. This wiring doesn't contains direct information about reset request!

There are two points:

a) The hardware-reset is acted by something on the USB device (that which receives the connection request).

b) The connecting host (that which requires the connection) may choose if require the reset or not.

I think, during the acknowledge, information flows (data bits)  on the data line driving the reset. If this is true, the SW driver of whom requires connection is (likely) responsible of a target reset-request and the USB device on the target is responsible to act the hardware reset.

Than the solutions to avoid reset should be alternatively:

a) To act on the SW driver of the host (that which requires connection) avoiding the reset-request (this request is normally issued to set the target in a known state)

b) To act on the target (that which receives the connection reset) disconnecting the reset pin.


Those four wires are connected to an FTDI chip on the arduino.  The FTDI chip communicates with the PC through the USB port.  It communicates with the microcontroller through the Tx and Rx signal lines, BUT it has one other output that goes to the reset of the micro controller.  The FTDI chip pulls that line LOW whenever a connection is opened from the computer side.

Like I say, it's hardwired to do so.  It doesn't matter what else you do from the computer side.  If you open a connection to the com port from the computer, that FTDI will deliberately reset the micro controller on the board.

It only makes this reset ONCE as the port is opened, so you can work around it by holding the port open, rather than opening it anew for each transaction.  Or you can simply take into account that this reset is going to occur, no matter what.

Your arduino code can be written in a way that assumes it's going to be reset, often and without prior warning.  Your PC software can be written to assume there's going to be a slight delay when waiting for input (as the arduino does it's own little boot up routine).

Alternatively, you can make one of the minor hardware mods I suggested to prevent that reset happening at all.  Plenty of choices.


ultrasound sensors to produce a 3d rendering of a robotic arm's local environment, this will most certainly involve a processing sketch rendering an image as the scan is taking place, having that mode"initialized" by a button press on a MCU. Then i would look at writing a VB or processing interface to "schedule"  robotic arm based on accelerometer data (one sensor per every separate piece of apparatus used in the intended process) written to EEPROM in a "demonstration mode" in which you carry out the procedure for the robotic arm, using the keyboard in a java based application to write F to the serial for finish demonstration (and S for start) and it stores the  accelerometer data it collects during that period in SD storage MCU driven circuits.

MCU then writes to serial a prompt for the name of the robotic procedure to save it as in SD card.

 When the user selects the Auto mode (which in turn generates a prompt for user to select a scheduling of a certain number of robotic functions, (ie chemist mechanical action), the procedure can be called by typing its saved name into the serial monitor, which then produces a prompt for the rate of the robotic micromovement, ie "number of times in total you want this flask to administer 1 mL to flask 2" and then further prompted for S and F external clock values (which is used to dictate the frequency of the loop, in the quantity the user had specified initially in demonstration mode for that robotic procedure, hence speed of which the average speed of robotic arm must be in order toi achieve that many repititions the user requested in the scheduling for that period of time globally)
im a good observer. not the brightest but very curious.

that poor innocent dog died from AC. he died.


So just to paraphrase the above, a robotic extension arm with ultrasonic sensor taking a range of position and proximity values which are then written to serial and read by a  processing sketch designed to produce a 3 dimensional rendering on the PC of the geometry of a robotic mechanical arm's local environment that consists of "N" objects (chemical apparatus) you have positioned surrounding the sensor. ( the symmetry of the vast majority of chemical apparatus allows for a number of exploits you can use to minimize the amount of sensor proximity  samples needed to be saved to SD for each object. so the ultrasound takes care of your spatial variance.

you then use the accelerometers "stuck" on each piece of apparatus by a robotic extension (after which serial communication is carried out that results in the individual appratus being selectable by user from inside the 3d rendering a processing sketch made in reading from the SD card data the ultrasonic sensor wrote to it, allowing user to appropriately label the apparatus and later on refer to the apparatus by selecting that label which will appear for the user to select in drop down menu list in the time scheduling component of the user programming input required by the MCU units driving the robotic movement of the automata system to store the necessary information needed to execute that chemical procedure automatically when commanded to do so by the user writing its label to the serial interface, to record the movement of the apparatus as a mechanical system in time as you require in the procedure

so EEPROM or SD storage i suppose depending on scale in regard to the number of individual apparatus components needed at most and their individual sizes, how long the rendering process takes, its quite an undertaking.
im a good observer. not the brightest but very curious.

that poor innocent dog died from AC. he died.


I was following everything until arduidiot. Is this an idea you have for another part of the system, or is what you are interpreting I was going to do with mine?

I wanted to post the progress on the drip sensor. Now that I am back, I 3D printed the laser sensor body, and then reworked it to have a karate chop action hinge and a triple laser array. Check it out. I had one laser, which was catching 75% of the drips unless the container was tiled to allow drips to slide in the path of the laser. I added the 3 lasers, still pointing to 1 photoresistor. It covers more of the area, but unfortunately it drowns the resistor in light, which catches 0% of the drips.

I had hoped that it would have worked, but I will need to rework the design. 3 lasers and 3 resistors methinks, or one laser with a line that is wide enough to cover the entire piece of glass and multiple resistors.

I also am going be switching to a straight distillation extension instead of the angle adapter. Shooting through 4 layers of curved glass is problematic, and for liquids that do not have a lot of surface tension, there is no drip until it leaves the elbow.

MORE TO COME!! Its slow going because school is in full swing and all I am taking is science classes this semester.


oh sorry i was thinking along the lines of how to automate mechanical transport of chemistry apparatus! my bad!
im a good observer. not the brightest but very curious.

that poor innocent dog died from AC. he died.

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131