Manual entry is ok, stream is not about grbl

[simen]

Have you pulled the very latest version of stream.rb? I recently changed the protocol slightly.

Can you paste the output from stream?

[avanderpluijm]

yes, using the latest version. (also tried the previous version which was working, with no acceleration).

I am sending this test code:
G21 G90
(profile 1)
G0 Z15
G17
M3
G0 X0.7695431472081218 Y-2.014467005076142
G1 Z-1.5 F100
G1 X160.7690355329949 Y-2.015228426395939 F500
G3 X163.2690355329949 Y0.4847715736040609 I0 J2.5
G1 X163.2690355329949 Y83.27664974619289
G3 X160.7690355329949 Y85.77664974619289 I-2.5 J0
G1 X0.7690355329949239 Y85.77664974619289
G3 X-1.7309644670050761 Y83.27664974619289 I0 J-2.5
G1 X-1.7309644670050761 Y0.4847715736040609
G3 X0.7690355329949239 Y-2.015228426395939 I2.5 J0

The result differs from time to time. When I do an Arduino reset before most of the times it shows:
G21G90
Grbl >>
Grbl >> Grbl 0.6b
Grbl >> '$' to dump current settings
_
So it looks like the code is interfering the startup. Stopping and starting again (no reset):
Processing file profile.gcode
G21G90
_
or
Processing file profile.gcode
G21G90
Grbl >> ok
G0Z15F100
Grbl >>
_

Trying with stream.rb file -p gives some more response (until halfway) but is not the desired method i guess.

[simen]

Thanks. I'll have a look at this tonight

[avanderpluijm]

well, looks like the stream.rb is not the problem. Probably it has something to do with the Arduino. I upgraded a 168 to 328. 168 version was ok, this one gives troubles.
I will let you know what happens.

[avanderpluijm]

sorry, accidently closed this issue. I guess my issue is more related to my own computer than grbl/stream or the arduino. It worked once yesterday, but it is unclear why...
Now first some testing with other computers.

[avanderpluijm]

ok, I seem to have tracked down the issue finally. Somehow the G3 command gave problems. I believe it should work because it is a A328, but that needs some more testing.
I made an AIR application, with a socket connection, and serproxy for the usb-air connection. It seems that the 'ok' response is sometimes received as 'o\n' and 'k\n'. So the loop i wrote stopped since it didn't receive 'ok' anymore. This can be addressed by implementing a handshake in GRBL, as mentioned in another issue.

So, my issue is closed ( for now:) )

[simen]

Thanks. I'll have a look at it.