Shop OBEX P1 Docs P2 Docs Learn Events
Serial communication, FLip and BlocklyProp — Parallax Forums

Serial communication, FLip and BlocklyProp

AutomaxionAutomaxion Posts: 26
edited 2020-08-21 10:54 in Learn with BlocklyProp
I am frustrated. I wanted to use a FLiP connected to a weighing balance, hoping to use USB (and an RS232 to USB converter). Apparently, that is not feasible.

I then thought I could directly use RS232 since that is what the balance uses. In Blockly under Communicate Protocols there are serial blocks but I cannot determine how to physically wire the FliP to the RS232 so that I can do anything with these. Attached is the Serial Initialize block description but I don't see how that relates to wiring CD, RxD, TxD, DTR, DSR, RTS, CTS RI which are standard cable connections for RS232 (I know some of these are not always needed)

Can anyone help?

Comments

  • kwinnkwinn Posts: 8,697
    For a lot of systems that output RS232 serial data I have found that connecting RX to TX , TX to RX, and sharing a ground is all that is needed in the way of connections. Occasionally RTS and CTS signals are also needed.
  • jmgjmg Posts: 15,140
    Automaxion wrote: »
    I am frustrated. I wanted to use a FLiP connected to a weighing balance, hoping to use USB (and an RS232 to USB converter). Apparently, that is not feasible.

    I then thought I could directly use RS232 since that is what the balance uses. In Blockly under Communicate Protocols there are serial blocks but I cannot determine how to physically wire the FliP to the RS232 so that I can do anything with these. Attached is the Serial Initialize block description but I don't see how that relates to wiring CD, RxD, TxD, DTR, DSR, RTS, CTS RI which are standard cable connections for RS232 (I know some of these are not always needed)

    Can anyone help?

    I'm unclear here - do you want the FLiP project to finally look like standard RS232 to some host, or does the weighing balance use RS232 ?
    It may be simplest to first define what pins the weighing balance actually needs to operate ?
  • Duane DegnDuane Degn Posts: 10,588
    edited 2020-08-22 03:26
    I know it's not a large sample size, but I've used the Propeller to communicate over RS232 with two different balances. Neither balance required the use of the RTS or CTS lines.
    I used an appropriate RS232 chip to translate the voltage levels. Apparently there are ways to keep the Propeller safe without the special chip but I wanted to play it safe.
    Often the RTS and CTS lines are only needed if you want to push the communication speeds up to near the limit of the device.

    Edit: I just reread your post. What do you mean by this:
    Automaxion wrote: »
    hoping to use USB (and an RS232 to USB converter).
    Does the balance have a USB port or a RS232 port?

    Edit again: I don't see any reason to involve USB is the balance has a RS232 port. The Propeller can not easily be a USB host device.

  • Duane DegnDuane Degn Posts: 10,588
    edited 2020-08-22 03:29
    This is the type of chip I used with my balances. You just define the RX & TX pins and baud with Blocky and I think it should work fine.
  • There's some duplicate information posted in this and the other thread on this topic. Starting multiple threads on the same topic is not a polite way to ask for help.
  • Cluso99Cluso99 Posts: 18,066
    With that blocklyprop seial, you will need to set the tx and rx pins, the baud (technically it's is baud not baudrate as baud implies rate), and the mode.
    Now, if you just use a series resistor to connect to RS232 you will need to set mode to invert.

    So, what is the scale you intend to use (provide a link)? From this we can see what RS232 pins are required - it may just be Rx and Gnd. Also we can see what RS232 voltage it is using, and then recommend resistors to protect the prop without using an RS232 chip. Otherwise use the Sparkfun board that Duane linked to.
  • I first must thank all of you for responding and for the information. I spent a long while on Friday searching the internet and reading and only just today, Monday, came back to this post. I have now ordered the SparkFun board but also, before, found the same chip mounted on my old Basic Stamp Pro Development board which I used to connect the chip to the RS232 of the Mettle Toledo Balance ME204 balance. I also alternatively connected the balance via an RS232 adapter to the USB of my PC. Now, so far, I can control completely the balance through a terminal program (Termite) and get all the expected responses. However, when using the Propellor and setting the baud and pins in Blockly Prop, I get only incomplete messages. Currently very often, the weight without the preamble and units (such as 0.0000 or .0000) or sometimes just S. I am assuming it is due to lack of handshaking when wired through the 3232 chip to TX and RX of the balance RS232 with the letter S which being part of the preamble in the response MT-SICS Interface Commands (https://www.mt.com/mt_ext_files/Editorial/Generic/7/MT-SICS_for_Excellence_Balances_BA_Editorial-Generic_1116311007471_files/Excellence-SICS-BA-e-11780711B.pdf)

    This is from those balance instructions ( _ represents a space character):

    Command SI Send the current net weight value, irrespective of balance stability.
    Response S_S_WeightValue_Unit (Stable weight value in unit actually set under unit 1)
    S_D_WeightValue_Unit (Nonstable (dynamic) weight value in unit actually set under unit 1)
    S_I (Command not executable (balance is currently executing another command, e.g. taring))
    S_+ (Balance in overload range)
    S_- (Balance in underload range)

    An example of what I should get is S D 0.0021 g, but all I get is S or 0.0021

    I plan to continue trying things out but any tips and pointers would be helpful.
  • I don't know how the UART buffers in Blocky work. I've used serial devices with the Propeller many times. As long as a sufficiently large buffer is used, I generally don't have trouble with missed characters. I almost always program the Propeller with Spin. I tried Blocky. I think it's fun and easy to use but I also think it quickly becomes cumbersome with larger programs.
  • Trouble is, I am a chemist, not a computer wiz and used Blockly as a quick and easy way to get the thing working. I was hoping not to have to become a programmer...

    So how do I find out (and increase) the buffer size in Blockly?
  • Oh, I forgot to mention, I had to use the wiring set up on the balance side here to get anything: https://www.lammertbies.nl/picture/db9_null_loop.png


  • Automaxion wrote: »
    Trouble is, I am a chemist, not a computer wiz

    I'm chemist as well. I started using microcontrollers to make it easier to record data. I soon found microcontrollers were more fun than chemistry and now I do more microcontroller work (designing PCBs and programming) than I do chemistry work.

    Add the ability to record balance data was a huge help when I worked as a chemist. An even bigger help was putting barcodes and all the containers. When samples were transferred, the original container and the new container where both scanned. This was all recorded to a csv file which made record keeping much easier and much more accurate.

    Here's the thread discussing the barcode scanner.
    Automaxion wrote: »
    So how do I find out (and increase) the buffer size in Blockly?

    I don't know the answer to this myself. I don't use Blockly much.
  • Well, I managed to get something working. I could not get the whole string I expected but did get the important part with some occasional errors that I could filter out. Using a SparkFun Transceiver Breakout ‑ MAX3232 was the key along with using the correct 98 ms pauses in the program when reading the serial. It's not brilliant, but will do for now.
  • Automaxion wrote: »
    will do for now.

    Blockly can work much better if you take advantage of the Propeller's multiple cogs.

    How many "new processor" blocks do you have in your program? If the answer is zero, you're doing it wrong.

    If you post your code, someone here might be able to help optimize it.



  • Blockly can work much better if ... it didn't interpret a space character as a null character when using serial receive block :-( Apparently, this is a common C programming error but not corrected in BlocklyProp.
  • With help from MatzElectronics, the attached works well for getting data from a Sartorius balance. Maybe others will find it useful.

Sign In or Register to comment.