Go Down

Topic: VB Comms Failure During Long Jobs (Read 3 times) previous topic - next topic

aibonewt

This thread has become somewhat of a soliloquy, but no matter. It's still useful for me to keep a record of what I'm trying, and much neater than the ever-thickening stack of sticky notes accumulating on the edge of my machine.

Not sure I can quite blame VB/MS just yet. I did a rebuild of my VB app using .Net Framework 2.0 as there are many reports going 'round that 3.5 is bad news for serial comms. The machine still froze after that, so I added a Try/Catch around the serial sending sub in the VB. Okay, it froze again after about 11 hours, but something unexpected happened. I had coded the serial exception to throw out messagebox with the error, but there was no box when the machine froze!

May be the Arduino misbehaving after all, but just to be sure I have started another test job with a camera watching the Tx/Rx lights on the Arduino. Hopefully, when it freezes again I will be able to play back the footage and see if that little Tx flashed before the machine stalled.

Onward...

aibonewt

Okay, for those of you still reading, I now have photographic evidence that this is NOT a VB error, but an Arduino one! Here we go...

Job Start:


Logfile Entries (camera clock was a few seconds out of sync):
Code: [Select]
Start of Matrix Output...
13:53:35 <- z-412
13:53:37 -> OK
13:53:37 <- x0y1
13:53:37 -> OK
13:53:37 <- x7058y0l3o0s1c7g19i262o0
13:53:59 -> OK


Job End: (moved camera and switched to a lower resolution)


Logfile:
Code: [Select]
02:05:45 <- x-7058y1
02:05:54 -> OK
02:05:54 <- x7058y0l3o14s1c7g19i261o15
02:06:16 -> OK
02:06:16 <- x-7058y1
02:06:26 -> OK
02:06:26 <- x7058y0l3o14s1c7g19i261o15


I'm now trying another test at only 9600bps to see if that helps. If not I might try and restart this thread under a new guise, after all it is a different problem to the one I thought I had originally!

PaulS

Quote
I now have photographic evidence that this is NOT a VB error, but an Arduino one!

Sounds like a conspiracy movie. I've never understood them because the photographic evidence that is supposed to prove something never does, to me.

Please explain what this photographic evidence is supposed to prove.

aibonewt

Hi Paul,

The shots were extracted from video of the UNO while my laser cutter was running. The serial transfer is a very simple polling scenario.

1) The VB app sends a command string, and waits for an 'OK' from the Arduino
2) Arduino catches the string and parses the variables <- RX flashes
3) Arduino carries out motor/laser commands
4) Arduino finishes and sends 'OK' back to the VB app <- TX flashes

And so on...

The photos show that the stalling is a fault with the Arduino or its code because the TX does not flash at the moment of stall (the last photo). Thus no 'OK' gets returned to VB. I had assumed for ages that VB/Windows was locking the port for some reason and not receiving the 'OK'.


PaulS

Quote
The photos show that the stalling is a fault with the Arduino or its code because the TX does not flash at the moment of stall (the last photo).

You can see from this picture that the Arduino code failed because of what isn't here. OK. Got it.

You've, of course, posted ALL of your Arduino code, and I just missed it. Right?

Code: [Select]
  inStr.reserve(40);          // easily enough for longest command (ie.x7000y7000z1404o13s0c19g6i270o14)
In spite of all the warnings about problems with the String class, you are still using it. Here's a gun. Shoot your self in the foot. Go ahead and do it again. There's plenty of bullets, and I'll reload when you run out.

Go Up