Hi Joel,
The issue we are seeing does not involve “the other side”. It is a simple loopback to the same UART, so the divisor should not matter, it is using the same clock in an out, right?
Yeah. In that case it shouldn't matter. That all should be the same bit length value no matter how bad the math really is
Mark
If the CSR value is a divisor, it is possible that the clock rate division math ends up with a bit time a bit off what the other side is using. I've seen this at higher baud rates where the math results in a very small value but not a larger
value.
Anyway, you could check the length of a character on a scope or just fiddle the divisor up/down a bit and see if it works.
Hi Andrew,
Following your instructions, I have now added the 300 and 600 baud rates in the tyGSOctal.c code and recompile my apps. Interestingly, with both the baud rates (300 and 600) I could successfully communicate with loopback but the problem
still exists with the 1200 baud rate. Does this indicate that noise problems only exist with a 1200 baud rate? How can check this noise in a scope trace?
On Nov 3, 2023, at 12:32 PM, Johnson, Andrew N. <anj at anl.gov> wrote:
Without seeing a scope trace I wouldn't completely rule out the possibility of noise from the VME chassis or the IP carrier board.
The driver code for setting the baud rate is the routine below from tyGSOctal.c. You could add options for 300 and 600 baud, those would need register values of 0x44 and 0x55 respectively (110 baud would be 0x11).
LOCAL STATUS tyGSOctalBaudSet(TY_GSOCTAL_DEV *dev, int baud)
SCC2698_CHAN *chan = dev->chan;
switch(baud)
{ /* NB: ACR[7]=1 */
Complexity comes for free, Simplicity you have to work for.
- The corruption may have something do with noise on the data line, say a few spikes that just happen to fall at the same time as some of the data bits at that specific baud rate.
I don’t think that can be the problem. We are seeing this with a 1” loopback wire from pins 2-3 on the Greensprings breakout. We are seeing the identical behavior on 2 completely different systems in 2 locations.
I also don’t understand why 300 and 600 baud say they are not supported, since the Ip-Octal-232 datasheet says it supports 18 baud rates starting at 50 baud.
Could it be the interface between drvAsynSerialPort and the Ip-Octal driver? The baud rate support in asyn has changed over time.
I have looked at the code in IPAC's tyGsOctal.c VxWorks driver and cross-referenced the bit-rate register settings with the UART data-sheet and I don't see why the 1200 baud rate shouldn't work. The only difference is the 1 byte value written
to one register. The corruption may have something do with noise on the data line, say a few spikes that just happen to fall at the same time as some of the data bits at that specific baud rate.
If I were investigating in detail I might try some different data patterns to see whether the data corruption is a fixed pattern or is somehow related to the data being sent out — a series of spaces and/or '@' signs would only have one
bit set in each byte. This might need a scope on the data line to look at properly though.
Complexity comes for free, Simplicity you have to work for.
I tested with my VxWorks system in the sector 13 electronics lab today. I reproduced the behavior Mrinal is seeing. This is all different hardware from Mrinal’s.
I put a loopback from pin 2 to 3 and used the asyn record to send a string and read the response. It works fine with the following baud rates:
300, 600, and above 38400 report that the baud rate is not supported on the VxWorks console.
1200 does not report that it is unsupported, but the readback is incorrect, it does not match the output.
If 1200 was previously working at APS beamlines then we need to figure out if there was a change to the driver that broke it.
Mark Rivers made the suggestion to change the settings. Which is a good suggestion of course. To that I would add, for me, the next thing I would do is get on the port and sniff the traffic.
Let’s go off-line (off tech-talk) for now, you can bring me your boards and I can test them if you want.
Although the RS-232 settings for Lakeshore 330 are (Baud rate:1200bps, Parity: Odd, Stop bits:1, Data bits: 7), I tried to test the loopback with your suggestions (data bits: 8, parity: none), and got different input/outputs for 1200 baud
rate as shown in the attached image. With 2400 and above baud rates the input/output values are the same as expected.
The IP-Octal modules I am trying to set are old modules from SBS. We have ordered some new ones (IP-520) from Acromag, but I haven’t yet received them. We will look into the Moxa option as well.
ioc3idb in sec.3 is running a LakeShore330 at 1200 baud, using the VME/IP-Octal.
Mostly these days we use Moxa “device servers” to run RS232 ports, I see some examples of the LakeShore330 being run this way here.
Just as a longshot, what company built your IP-Octal-232 modules? Did these come from the old supplier (SBS?), or did they come from an “Artisan” type company that does re-pops of legacy hardware? If the latter, I would be suspicious.
IIRC we actually moved away from the IP-Octal-232 in favor of an Acromag (IP520?) board, towards the end of our VME era. These days much prefer a Moxa.
I checked the setup with two IP-Octal-232 modules, and they both showed similar behavior. I have been using Lakeshore so far but with soft IOC using on a Raspberry Pi computer. This is the first time I am trying to interface it through
VME and the IP-232 module. Can you tell me which beamline at APS is using Lakeshore through VME?
Your loopback test results suggest a hardware problem to me. Have you tried the test using a different (or new) IP-Octal-232 card? Also, I would send more and different characters, to see if any patterns or other failure modes emerge.
LakeShore 330’s have been used here at the APS, at 1200 kbps, from what I can tell searching through ioc setup files.
Hello,
While configuring RS-232 communication through XM-octal breakout boards with TVME-200 (with IP-Octal serial module) and MVME3100 using EPICS 7.0 and vxWorks-6.9.4, I did some quick tests with asynRecord. I found the following:
1) With loopback communication(when I sorted the 2 and 3 terminals of the RS-232 ports) with the baud rates of 2400 and above, I received the same input and output values (as shown in the 1st attached image). That shows that RS-232 communication is OK.
2) With the baud rate of 1200, the Output and Input values of asyRecord are different (as shown in the 2nd attached image). I suspect either the tyGSModule or TVME-200 with IP-Octal Serial board has some issue with communication baud rates below 2400.
When I checked the IP-Octal Serial module documentation I found the baud rate information as ‘Programmable in 18 steps to 34.8kbps’. I dug further into the information regarding the baud rate of the chip used in the module (i.e SCC2698B). I found that the chip
supports 26 fixed baud rates from 50 to 38.4kbps. Hence, I think 1200 kbps should be supported by the chip and IP-Octal Serial module.
I need the baud rate of 1200kbps to interface the Lakeshore 330 temperature controller with EPICS on VME hardware. Did anybody try to interface Lakeshore 330 with VME and IP modules?
Best regards,
Mrinal
- References:
- Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mrinal Bera via Tech-talk
- RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Goetze, Kurt via Tech-talk
- Re: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mrinal Bera via Tech-talk
- RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Goetze, Kurt via Tech-talk
- Re: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mrinal Bera via Tech-talk
- RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Goetze, Kurt via Tech-talk
- RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mark Rivers via Tech-talk
- Re: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Johnson, Andrew N. via Tech-talk
- RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mark Rivers via Tech-talk
- Re: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Johnson, Andrew N. via Tech-talk
- Re: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mrinal Bera via Tech-talk
- Re: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Joel Sherrill via Tech-talk
- RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mark Rivers via Tech-talk
- Navigate by Date:
- Prev:
RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mark Rivers via Tech-talk
- Next:
Re: Every thing is working Tran, Phi Dung via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
<2023>
2024
- Navigate by Thread:
- Prev:
RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mark Rivers via Tech-talk
- Next:
RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mark Rivers via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
<2023>
2024
|