Connecting Unistream to LoPy via Panel USB Port

[ETURSON]

I have a LoPy device as shown in the link below:

https://pycom.io/hardware/lopy-specs/

I also have the Unitronics US5-B10-TR22. I am trying to connect US5-B10-TR22 to LoPy via Silicon Labs CP210X USB to UART Bridge. 

I enabled the Panel USB Port as TX/RX from Physical-Controller USB Port. Then I used Com TX to send data to LoPy as shown below and I also attached the simple code I wrote. But I never succeeded sending any data. The Com module gave me error code -1, which is general com error. I never programmed Unistream before and I am just learning. Can I communicate to LoPy via Panel USB Port? If yes, how can I do so?  

FirstProgram.ulpr

[Ofir]

Hello,

Please make sure that you are using USB to Serial based on  "PL23203 USB to Serial/UART Bridge Controller".

You'll have to use it to be able communicating between the LoPy and UniStream  controller.

[Dancho]

I really hate for my first forum post to be resurrecting a dead thread, however I'm doing this identical thing and having issues.

Eturson, did you get this working?

 

I am using a CP2102 converter chip on an ESP32 dev board (https://docs.zerynth.com/latest/official/board.zerynth.doit_esp32/docs/index.html).  Amazon will be delivering a PL2303 USB to TTL adapter this afternoon.  I'm hoping this fixes me.

I initially had all working well directly from the USB host port to the micro-USB on my dev board.  This worked until the next time the system was turned on (???).

[AlexUT]

1. You have to use Prolific based USB to Serial converter. Other models are not supported.

2. In Ladder you must to use Set request/process command/reset request.

If your ladder is similar to one in this post, then transmit will be processed at each scan, and will lead to owerload and errors.

 

[Dancho]

Prolific is what is supported, however I assume it is not unheard of for other hardware to work sporadically?  This is what I'm waiting on (https://www.amazon.com/gp/product/B07R8BQYW1/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1).  Do you think this is what I need?

Here is my ladder for outputting the message(s) and the setting/resetting "send".  I think I have an issue with my algorithm for cycling through messages.  Shouldn't be a hard fix- it only sends the first message, never cycles through which messages.  (I changed the original message to a few smaller messages in case the length was causing problems for my MCU.  It was not.  May change back).

 

I appreciate the help.  Ladder is new for me, but I've got lots of programming and electronics experience otherwise.

 

 

 

 

[AlexUT]

Take care that output of this adapter from Amazon is TTL 3.3V.

LoPy device link is invalid, so I cannot see what is a device input voltage level, TTL 3.3V or RS232, which is from +-15V to +-6V.

 

[Dancho]

My TTL 3.3V converter arrived.  All worked well for about four hours.

During that time, I updated the program on the PLC and combined the output strings from 4 into 1.  Since then, my serial broadcasting device can't make out a single character from the PLC USB port.  The TTL converter has a PL2303TA, and I think I've ruled out that the signal 'became' inverted, or otherwise.  Using a USB-RS232 and an RS233-USB I've confirmed the string is transmitting.

 

My next steps:

Change to a faster baud rate (19200 -> 115200)

Lower delay time (50 -> 5 mS)

....

Shorter string/multiple messages?

 

I've got a terrible oscilloscope, but it's enough to measure voltage levels.  Is there anything I can do to suss out what my MCU is seeing?

[Dancho]

I've tried a faster baud rate and a lower delay.  I have not shortened the string length.  Buffer size is adequate I believe.  No change.

 

I am very hesitant to point towards the PLC as the issue, but I am starting to lean that way.  Especially since it worked flawlessly during the first boot up, then never again.  Is there a way to rule out driver issues/ Prolific chip authenticity?  What about flow control?

Is there anything I could be missing?

 

For reference: USB to TTL converter (https://www.amazon.com/gp/product/B07R8BQYW1/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1)

 

[AlexUT]

Go to Prolific site and look for prolific chip identification software.

There are china maden chips, which are not authentic and driver reject to work with these chips.

This may be a reason.

 

[Dancho]

I got the EEWriter tool to invert signals if needed.  It seems to have an authentic chip.  VID and PID seem fine (devicehunt.com confirms).  It says EEProm not written yet, though I'm not sure why that would make a difference...

I also used the Prolific CheckChipVersion tool, and it doesn't appear to be counterfeit?

 

 

 

Beyond that, my next guess is possibly STX and ETX on the string?  Though I did not need them previously, as I mentioned, all serial comms were fine.

[Ausman]

Get a port monitor and do things on the PC to start with, noting interactions that work.  Much easier than constantly trying things on the plc.  Once you find what works, you're almost home.

On 11/8/2019 at 1:17 AM, AlexUT said:

LoPy device link is invalid, so I cannot see what is a device input voltage level, TTL 3.3V or RS232, which is from +-15V to +-6V.

I think this needs to be looked at closely, too.  You simply may not be getting enough signal change and it might have blown itself up due to working too hard?  Hence only working for a while.

cheers, Aus

[Dancho]

Solved.

Even with an appropriate buffer size, the string length apparently affects the stability of the serial TX from the USB port.  Below some threshold (haven't pinpointed the exact size), the serial comms are hit or miss.  (String length is roughly related to number of tags within the strong, so that may also be the culprit)

 

Previous buffer size was ~125ish bytes, and full string showed with a USB-RS232 and RS232-USB, but nothing on the Prolific device, etc.

Now two strings ~75 bytes reliable communicate with a CP2012, PL2303TA (prolific) no problem.

 

I'm at a loss for why, but that's what I've found...

[Dancho]

I hate to revive this topic, however, I'm continuing to have issues related to serial TX from the USB host port.  ....Frustrating.

 

I took my working project, added two messages to be triggered once by the General.Initial Cycle bit aaaand....ALL the serial TX ceased to work, not just the boot up message.  My MCU is set to flash the onboard LED when Serial.available() = true.  I'm imagining it is detecting the voltage drop for the first bit.  That happens and happened with the previous issues, however If my MCU sends any MQTT messages at all they are almost entirely 0x00 and few 0xff.  Message sizes are between 21 and 68 bytes.

 

The flow control scheme was the following, increment a counter every second, loop to 0 when greater than 8.  Send a specific message if the counter is 2, 4, 6 or 8.  When the initial cycle bit is 1, start counter at -4, send a specific message at -2 and 0.

 

Previous working project had 1 CPU Protocol Message, 4 total messages, no checksum, no STX, ETX: 0x0A.

Non working project has 1 CPU Protocol Message, 6 total messages, no checksum, no STX, ETX: 0x0A.

 

In online mode the rungs get powered at the correct counter increments.  Am I supposed to see the rungs turn red the whole way to the end??

 

 

Other things that were different/ correct actions taken:

I added a ladder just for message sending rungs, and added it to the main routine.  I made other changes unrelated to Message Composer.  When I tested the serial comms and noticed the issue, I removed the initial cycle rung.  No change.  I removed the additional messages.  No change.  I removed the additional ladder, and replaced the rungs on the ladder from the working project.  No change.