Loosing serial com

Mrlaser

We use a Javelin to control some of our equipment with a RS232 com link to a controlling computer. The Javelin controls that actual operation of the equipment (it is incorporated in a custom control circuit), and the "controlling computer" sends commands to the Javelin as to what operation the equipment needs to perform.

Every once in a while, we have problems that some Javelin seem to loose communication with the controlling computer for no apparent reasons (the Javelin is no longer responding to commands sent by the controlling computer). We also had some random occurence of the Javelin freezing up in any given state (again for no apparent reason).

One thought that came up could be that the ambient temperature (inside the cabinet where the Javelin is mounted) might be a factor. I tried to look up on your web site and could not find any specification or information about the aceptable operating temperature range for the Javelin. I know I could probably go through the list of all the individual components, but that seems a bit drastic, and I would think that you guys at Parallax should have done this.

So does anyone know what the acceptable range of operating temperature is for the Javelin? And does anyone know if this could explain our "communication loss" problems?

Thanks.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lasers will rule the World!

Peter Verkaik

The parallax main javelin page
http://www.parallax.com/javelin/index.asp
specifies 0-70 degrees celcius.

There can be numerous reasons why communications fail.
Without knowing the·code, it is impossible to tell.
It could be your code does not account for badly received bytes
and that you did not anticipate these possibilities. If your communication
incorporates a checksum then you can assume it is not the protocol code.
One reason is possibly a while loop that never exits because a condition
is not met, so the javelin appears to hang, but actualy is just waiting,
Eg. waiting for an acknowledge bit of an I2C chip.

regards peter

Mrlaser

Thank you very much for your response. I apologize for missing this (rather obvious) temp spec.

Thanks for the notes on the com issues. I will look into this in more details. I believe our communication protocol should take care of these problems, exept maybe the issue of badly received bytes. The idea of having a checksum could be interesting, but I am not sure that we can implement that (I need to think about that).

You have seen the actual code, bpwillie had sent it to you about one month ago. We are still struggling with spurious problems. But we are making progress.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lasers will rule the World!

Peter Verkaik

If that code is the same that you use now, I will take a look at it,
to see if there is something that could make the javelin "hang".

regards peter

Mrlaser

Yes, the code is the same.
Regards,
FD

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lasers will rule the World!

Peter Verkaik

I removed the BPI code from the Uart class and put it in its own class.
Then in LaserController.java I defined

· private BPI m_BPI;········· // Virtual Peripheral for LCD display
· private Uart m_LCDcom;····· // Virtual Peripheral for LCD Uart

· public
· LaserController()
· {
··· m_LCDcom = new Uart(Uart.dirTransmit, LCDpin, Uart.invert, Uart.speed9600, Uart.stop1);
··· m_BPI = new BPI(m_LCDcom);

and replaced m_LCDcom.xxx by m_BPI.xxx where xxx is the BPI method, now in class BPI.

It is better to have more small classes than a few large classes. And the Uart class was already
large.

I checked your SerialCom.java class and noted it uses StringBuffer.
I never use StringBuffer (I always use char[noparse]/noparse and Format.bprintf() to convert numbers/text to strings) so I will
look into that.
I noticed you use
····· System.out.println(e.getMessage());

but e.getMessage() always returns an empty String so that statement is pointless.

regards peter

Peter Verkaik

In SerialCom.java you use StringBuffer.indexOf().
The distributed StringBuffer has an error in that method.
The correct version is

· /**
·· * Finds the first occurance of the specified String in this StringBuffer.
·· *
·· * @param str the String to search for.
·· * @return the index of the first character matching the String or -1 if the
·· *·· String is not found.
·· */
· public int indexOf(String str) {
··· int start = -1;
··· int count = 0;
··· for ( int i = 0; i < length; i++ ) {
····· if ( str.value[noparse][[/noparse]count] == s[noparse][[/noparse]i] ) {
······· if ( start == -1 ) {
········· start = i;
······· }
······· count++;
······· if ( count == str.length ) {
········· return start;
······· }
····· }
····· else {
······· count = 0;
······· if (start >= 0) i = start+1;· //line added by Peter Verkaik
······· start = -1;
····· }
··· }

··· return -1;
· }

If you do not have this corrected version, that may be the source
of some of your errors.

Edit: It appears also in String.java there were errors in indexO() and append().
So I attached both corrected versions.

regards peter


Post Edited (Peter Verkaik) : 4/17/2007 3:18:32 PM GMT

Mrlaser

Thanks a lot. We will test this.
Regards,
FD

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lasers will rule the World!

Peter Verkaik

I just tested the indexOf() because the +1 in my line appeared wrong.
And it was.

Attached a corrected String and StringBuffer class and indexof_test program.

regards peter