V0.12.0 introduces connection issue

[splendiduser]

I have an Arduino mega2560 board and it works fine with V0.11.0 including an add-on I wrote. However, when testing things with V0.12.0, I cannot connect with the Arduino anymore. It doesn't seem to be add-on related and I could break it down to simply trying to run scanForArduinos twice in a row without any custom add-ons in the path. V0.11.0 simply gives me the connected device twice. V0.12.0 only works in the first call after arduinosetup() and results in an empty cell afterwards. Trying the 'debug' option gives me: "** initArduino: failed valid response err=1 - Undersized packet header". Could it be that scanForArduinos() doesn't release the connection properly?

[lostbard]

It should, buts its possible i guess. The main change with 0.12 was the use of of the serialport object instead of the serial object.

Can you provide the output of scanForArduinos("debug") for the 1st and 2nd attempt.

Also what OS are you using, and which version of instrument control and which version of octave ?

[splendiduser]

Sure, sorry. So I'm using Windows 10 22H2, Octave 8.4.0 and instrument-control-0.9.1. And this is the output:

>> scanForArduinos('debug', true)
* trying comport COM1
>> 165 0 1 0
<<
 ** __initArduino__: failed valid response err=1 - Undersized packet header
* trying comport COM4
>> 165 0 1 0
<< 165 0 1 7
<< 30 152 1 1 50 5 0
>> 165 0 8 1 0
<< 165 0 8 5
<< 0 67 111 114 101
>> 165 0 8 1 1
<< 165 0 8 4
<< 1 73 50 67
>> 165 0 8 1 2
<< 165 0 8 4
<< 2 83 80 73
>> 165 0 8 1 3
<< 165 0 8 6
<< 3 83 101 114 118 111
>> 165 0 8 1 4
<< 165 0 8 14
<< 4 83 104 105 102 116 82 101 103 105 115 116 101 114
 ** found board mega2560
ans =
{
  [1,1] =

    scalar structure containing the fields:

      port = COM4
      board = mega2560

}

>> scanForArduinos('debug', true)
* trying comport COM1
>> 165 0 1 0
<<
 ** __initArduino__: failed valid response err=1 - Undersized packet header
* trying comport COM4
>> 165 0 1 0
<<
 ** __initArduino__: failed valid response err=1 - Undersized packet header
ans = {}(0x0)
>>

[lostbard]

Thanks - i take a look - it does appear to be working correctly in linux, so will have to look for if anything is happening differently in windows.

[lostbard]

Something I just thought of ... in scanForArduinos.m, at the bottom its currently:

      unwind_protect_cleanup
        if !isempty (s)
          clear s
        endif
      end_unwind_protect

change the clear s to delete(s) and see if that helps

[lostbard]

Running windows 11, and its not happening for me on scanForArduinos.

I can make it do it it I run:

a = arduino a = arduino

Which would try to open the arduino 2x and fail, unless there was a delete between them.

Adding the delete in scanForArduions should still be added and may be enough for it to work for you.

[lostbard]

Did you have a chance to verify if adding the delete in scanForArduinos worked for you?

[splendiduser]

Yes and no. I wanted to try it on a different computer but didn't have the chance yet. Since octave.org was down for most of the day I stopped working on it. I can only state one more observation: When using V0.11.0, connecting to the device with Octave only lit up the TX and RX LEDs. Using V0.12.0, the builtin LED (13) lights up twice briefly during the first connection with a = arduino("COM4") in my case. After using clear a and trying to connect again, the LED lights up permanently and the connection attempt fails as described above. So something is strange about the initialization.

[lostbard]

The light up more than once is to be expected in v12 as the check that it is an arduino is a little more robust (Perhaps it doesnt need to be, but wont effect anything else)

The changing from clear to delete scanForArduinos should be the fix.

[splendiduser]

On my PC, I have not found a way to make V12 work reliably, including replacing the clear s command. On a different computer with the same OS, Octave, and arduino package versions, the same device behaves as expected - out of the box, i.e., without replacing the clear s command. I don't know why that could be and I'm willing to accept this as a fluke of my system. I'm only using it here as a test bed for another computer. It's a bit unsatisfactory, but works for now. I don't have any ideas what more I can test.

[lostbard]

To be clear, this is also not working on scanForArduinos? (after changing to use delete(s) )

A related bug in octave rather than this package is assigning the octave 'ans' variable with the arduino object, but shouldnt effect scanForArduinos, and shoulnt effect arduino calls if delete is used on any rduino object before trying to open a new one.

[splendiduser]

Yes, on the problematic PC changing clear s to delete(s) did not affect the behavior. I also tried s.delete.

[lostbard]

hmm ... I am out of ideas on the issue currently.

I do have a new version I will be releasing soon that includes a few minor fixes. but I dont think it will help.

I guess when its released, give it a try and let me know

[splendiduser]

Thank you for your efforts. I will try it when it's out.

[lostbard]

https://github.com/gnu-octave/octave-arduino/releases/tag/release-0.12.1

[splendiduser]

I tried V12.1. It didn't change the status quo. Maybe it's just an issue of the hardware combination of the problematic PC. Anyway, I can work with it as it is now. Thanks. If anything changes in the future, I can report again.

[lostbard]

Thanks for the reply - if i think of anything else could try I will let you know.

On the positive side, it did identify a potential issue in the arduino package, and a bug in octave!

[lostbard]

Can you try with latest versions of arduino (0.12.1) and instrument-control (0.9.3)

[splendiduser]

Not until the end of the month, I'm afraid.

[lostbard]

that will be fine!