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.
--joel sherrill RTEMS
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?
Best,
Mrinal
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 */
case 1200:
chan->u.w.csr=0x66;
break;
case 2400:
chan->u.w.csr=0x88;
break;
case 4800:
chan->u.w.csr=0x99;
break;
case 9600:
chan->u.w.csr=0xbb;
break;
case 19200:
chan->u.w.csr=0xcc;
break;
case 38400:
chan->u.w.csr=0x22;
break;
default:
errnoSet(EINVAL);
return ERROR;
}
dev->baud = baud;
return OK;
}
- Andrew
Complexity comes for free, Simplicity you have to work for.
Hi Andrew,
-
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.
Mark
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.
- Andrew
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:
2400
4800
9600
19200
38400
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.
<image002.png>
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
Hi Mrinal,
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.
Kurt
Hi Kurt,
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
- Replies:
- RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mark Rivers via Tech-talk
- 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
- Navigate by Date:
- Prev:
Re: fanout is not working Tran, Phi Dung 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
2025
- Navigate by Thread:
- Prev:
Re: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module Mrinal Bera 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
2025
|