Can't make arduino object with a Mac

[EkpuzC]

I'm new to using a Mac (MacBook Pro, Sonoma 14.4) but have experience with Octave and Arduino in Windows. After pkg load arduino I can see this:

Package Name        | Version | Installation directory
--------------------+---------+-----------------------
           arduino *|  0.12.1 | .../cathy.zupke/.local/share/octave/api-v58/packages/arduino-0.12.1
instrument-control *|   0.9.2 | .../.local/share/octave/api-v58/packages/instrument-control-0.9.2
>>
The Octave version is:
>> version
ans = 8.4.0
>>

I can run arduinosetup and it will open the Arduino IDE and let me upload the code to an Arduino Uno board. That board can then work with Octave on a Windows machine, but when I try to make a connection on the MacBook I get this:

>> a=arduino('/dev/cu.usbmodem14201')
error: __initArduino__: failed get lib 1 err=1 - Undersized packet header
error: called from
    __initArduino__ at line 114 column 12
    arduino at line 133 column 16
>>

While more rare, I've also seen this:

>> a=arduino('/dev/cu.usbmodem14201')
error: set: H must be a graphics handle
>>

Unplugging the board and plugging it back in seems to restore it to the "Undersized packet header" state.

For what it is worth, when installing the instrument-control package, there were a lot of warnings but as far as I could tell, no errors.

[EkpuzC]

It looks like the Boards Manager says "Arduino AVR Boards 1.8.6".

I don't think it is a version of the code problem, but more there is something peculiar with the Mac USB communication or drivers that does not work and play well with the code on the Arduino. I think ultimately it is some sort of Mac specific issue as the different boards work fine with Windows machines, and the Arduino IDE works fine on the Mac as well. So, it is possible for USB based communication between the Arduino and the Mac to work fine (ie. via IDE), but the Octave software has trouble. That Octave software has two components, the packages we've been fiddling with, and the Arduino code loaded up with arduinosetup.

I'll switch over to the Mac and try arduinosetup without any libraries and post the results in another message.

[EkpuzC]

When I do arduinosetup with those libraries commented out, on a Windows machine a = arduino('COM7') worked fine and the resulting arduino object as an empty cell array for the list of libraries. When I run testarduinoconnect2.m on the Mac with that board (the Elegoo), I got:

>> testarduinoconnect2

port = /dev/tty.usbmodem14201
baud = 9600
readtimeout = 0.5000
Init arduino --------------------
a =

  Serial Port Object Serial-/dev/tty.usbmodem14201
    Port:     /dev/tty.usbmodem14201
    BaudRate: 9600
    Parity:   None
    DataBits: 8
    StopBits: 1
    Timeout:  0.2

cdata = [](0x0)
>> 165 0 1 0
<<
Undersized packet header
Error: res(4): out of bound 0 (dimensions are 0x0)
>> testarduinoconnect2

port = /dev/tty.usbmodem14201
baud = 9600
readtimeout = 0.5000
Init arduino --------------------
a =

  Serial Port Object Serial-/dev/tty.usbmodem14201
    Port:     /dev/tty.usbmodem14201
    BaudRate: 9600
    Parity:   None
    DataBits: 8
    StopBits: 1
    Timeout:  0.2

cdata = [](0x0)
>> 165 0 1 0
<<
Undersized packet header
Error: res(4): out of bound 0 (dimensions are 0x0)
>> testarduinoconnect2

port = /dev/tty.usbmodem14201
baud = 9600
readtimeout = 0.5000
Init arduino --------------------
a =

  Serial Port Object Serial-/dev/tty.usbmodem14201
    Port:     /dev/tty.usbmodem14201
    BaudRate: 9600
    Parity:   None
    DataBits: 8
    StopBits: 1
    Timeout:  0.2

cdata = [](0x0)
>> 165 0 1 0
<< 165 0 1 7
<< 30 149 15 0 50 1 0
boardid = 0
voltref = 5
numlib = 1
>> 165 0 8 1 0
<< 165 0 8 5
<< 0 67 111 114 101
lib: core
Init arduino done ---------------
>> testarduinoconnect2

port = /dev/tty.usbmodem14201
baud = 9600
readtimeout = 0.5000
Init arduino --------------------
a =

  Serial Port Object Serial-/dev/tty.usbmodem14201
    Port:     /dev/tty.usbmodem14201
    BaudRate: 9600
    Parity:   None
    DataBits: 8
    StopBits: 1
    Timeout:  0.2

cdata = [](0x0)
>> 165 0 1 0
<<
Undersized packet header
Error: res(4): out of bound 0 (dimensions are 0x0)

[EkpuzC]

I don't know if this might be a potential debugging strategy or not, but would it be helpful to try using a different utility to send and recieve the commands to the arduino? I downloaded RealTerm on my PC and played around with it a bit. I don't understand all the settings, but I was able to get 165 0 1 0 165 0 1 7 30 149 15 0 50 1 0 where the bold is what is sent and the numbers that follow are the response. It looks like I can replicate the

>> 165 0 1 0
<< 165 0 1 7
<< 30 149 15 0 50 5 0
>> 165 0 8 1 0
<< 165 0 8 5
<< 0 67 111 114 101

sequence. I'm doing this in Windows but maybe trying the same thing on the Mac we can see if the issues show up with a non-Octave program. I don't know if this would be diagnostic or not, but I may try to play around with this a bit. If you think this might be helpful and have ideas of what to try, let me know.

I thought about using Python to do this but https://stackoverflow.com/questions/48502300/writing-bytes-on-usb-device seems to imply that involves a URB and maybe that is what is going on under the hood in Octave. It is late and I'm rambling so I'm not sure I'm communicating what I'm thinking but I guess a potential hypothesis is that there may be something in low level code that happens to not work well with Apple hardware. If we find more examples of software that can communicate robustly, doing what we think Octave should be doing (that is sending and recieving bytes), then maybe that would point to a low level issue.

[lostbard]

You can do in python i believe - i will take a look - the fact that its a usb serialport vs a nonusb serial port shouldnt matter in python

By that I mean that stackflow question was about writing to a raw usb device, not about treating it like a a serialport.

[lostbard]

I created the test arduinoconnect as python script (rename to .py) You will need pyserial installed (pip install pyserial)

testarduinopy.txt

[EkpuzC]

Grades are in and I finally had time to install Python and pyserial and test out your Python script. Here are the results with the Elegoo board:

============ RESTART: /Users/cathy.zupke/Documents/testarduinopy.py ============
Init arduino --------------------
Serial<id=0x10210fe50, open=True>(port='/dev/tty.usbmodem14201', baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=0.5, xonxoff=False, rtscts=False, dsrdtr=False)
>> 165 0 1 0
<< 165 0 1 7
<< 30 149 15 0 50 5 0
boardid 0
voltref 5.0
numlib 5
>> 165 0 8 1 0
<< 165 0 8 5
<< 0 67 111 114 101
lib b'Core'
>> 165 0 8 1 1
<< 165 0 8 4
<< 1 73 50 67
lib b'I2C'
>> 165 0 8 1 2
<< 165 0 8 4
<< 2 83 80 73
lib b'SPI'
>> 165 0 8 1 3
<< 165 0 8 6
<< 3 83 101 114 118 111
lib b'Servo'
>> 165 0 8 1 4
<< 165 0 8 14
<< 4 83 104 105 102 116 82 101 103 105 115 116 101 114
lib b'ShiftRegister'
Init arduino done ---------------

I don't know what was different between my modified test script and the last one that you sent (testarduinoconnect2), but I think when I put the pause into that last script it didn't work. I just checked my original script with a pause and it does work. I'm including it here for reference: TwPause.txt

[lostbard]

So the python script did not ever seem to have issues reading anything?

I had looked at the pyserial code and hadnt seen anything that looked that different to what the octave code is doing. I guess may need to look again.

[EkpuzC]

Yes. I just did a bunch of repeated runs and no error messages of any kind.

It does seem like this is evidence that it is not necessarily an issue with the code running on the Arduino and that a reasonable approach would be to keep focussing on the Octave serial code. I wish there were more I could do to help out, but I'm not sure I have the knowledge and skills to be much help. I am on Spring break so I should have more time to do testing and I could possibly be another set of eyes looking at Python or Octave code if you tell me the right places to look.

I gather that the serialport object is the preferred one to use, but I'm wondering if a possible experiment would be to replicate your test using the serial object (in Octave) instead. I don't know if they have enough differences between them that it might be possible for one to work while the other doesn't. If that did happen, it might help narrow down what the issue(s) might be by seeing how they are different.

This may be what you were referring to when you said the pyserial code didn't look different, but when I tried to compare the documentation for the pyserial serial object to that for the Octave serialport, it wasn't obvious what the default settings for all the communication protocol parameters are in Octave. I could imagine explicitly setting or (maybe just checking) the different properties (like stopBits, parity, FlowControl, etc.).

[lostbard]

The serial object in octave also comes from the instrument control package.The initial testarduino script tried both ways, and didnt seem to make a difference one way vs the other.

Perhaps next thing to do will be create a oct file that mimics the serialport interface code from the serialport object and verify it is also showing the same issue.

I am also trying to find the redboard I have to see if it shows the same behavior in linux on a PC.

[EkpuzC]

The oct file strategy sounds decent, as does testing with Linux. I tried to test it on my Windows 11 machine with WSL but I couldn't get access to the usb port on the linux side. I think it may be a permissions issue, but I am a total Linux noob and couldn't figure it out. I used WSL USB Manager 5.3.0 (a Python based gui to make it easy to share USB devices via the usbipd utility) but I still couldnt' get it to work. I might go back to studying the TwPause code and then go and try modifying the Octave package code to see if I can learn something that way.

[lostbard]

Heres another py test that uses VTIME which is what octave is doing

testarduinopy2.txt

[EkpuzC]

The second python script seems to work just the the first one. No errors with the Elegoo board or the old Redboard:

Init arduino --------------------
Serial<id=0x103a3c100, open=True>(port='/dev/tty.usbmodem14201', baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=0.5, xonxoff=False, rtscts=False, dsrdtr=False)
>> 165 0 1 0
<< 165 0 1 7
<< 30 149 15 0 50 5 0
boardid 0
voltref 5.0
numlib 5
>> 165 0 8 1 0
<< 165 0 8 5
<< 0 67 111 114 101
lib b'Core'
>> 165 0 8 1 1
<< 165 0 8 4
<< 1 73 50 67
lib b'I2C'
>> 165 0 8 1 2
<< 165 0 8 4
<< 2 83 80 73
lib b'SPI'
>> 165 0 8 1 3
<< 165 0 8 6
<< 3 83 101 114 118 111
lib b'Servo'
>> 165 0 8 1 4
<< 165 0 8 14
<< 4 83 104 105 102 116 82 101 103 105 115 116 101 114
lib b'ShiftRegister'
Init arduino done ---------------

[lostbard]

ok - a oct file version. Rename to testserial1.cc (and change serial port name) and then in octave run

mkoctfile testserial1.cc

AT that point there should now be a function testserial1 that you can run.

[lostbard]

For the python script can you verify it ran the correct one (testarduinopy2.txt)? On my linux machne it printed the OS out before the Init line, and shows as VTIMESerial when running.

[EkpuzC]

I may have copied the wrong one since I ran it a bunch of times, but the bottom line is the same--it runs without issues on both problematic boards: Elegoo

OS darwin
Init arduino --------------------
VTIMESerial<id=0x1087bbd90, open=True>(port='/dev/tty.usbmodem14201', baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=0.5, xonxoff=False, rtscts=False, dsrdtr=False)
>> 165 0 1 0
<< 165 0 1 7
<< 30 149 15 0 50 5 0
boardid 0
voltref 5.0
numlib 5
>> 165 0 8 1 0
<< 165 0 8 5
<< 0 67 111 114 101
lib b'Core'
>> 165 0 8 1 1
<< 165 0 8 4
<< 1 73 50 67
lib b'I2C'
>> 165 0 8 1 2
<< 165 0 8 4
<< 2 83 80 73
lib b'SPI'
>> 165 0 8 1 3
<< 165 0 8 6
<< 3 83 101 114 118 111
lib b'Servo'
>> 165 0 8 1 4
<< 165 0 8 14
<< 4 83 104 105 102 116 82 101 103 105 115 116 101 114
lib b'ShiftRegister'
Init arduino done ---------------

and the old Redboard

OS darwin
Init arduino --------------------
VTIMESerial<id=0x1049fbe20, open=True>(port='/dev/tty.usbserial-DN03GDV8', baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=0.5, xonxoff=False, rtscts=False, dsrdtr=False)
>> 165 0 1 0
<< 165 0 1 7
<< 30 149 15 0 50 5 0
boardid 0
voltref 5.0
numlib 5
>> 165 0 8 1 0
<< 165 0 8 5
<< 0 67 111 114 101
lib b'Core'
>> 165 0 8 1 1
<< 165 0 8 4
<< 1 73 50 67
lib b'I2C'
>> 165 0 8 1 2
<< 165 0 8 4
<< 2 83 80 73
lib b'SPI'
>> 165 0 8 1 3
<< 165 0 8 6
<< 3 83 101 114 118 111
lib b'Servo'
>> 165 0 8 1 4
<< 165 0 8 14
<< 4 83 104 105 102 116 82 101 103 105 115 116 101 114
lib b'ShiftRegister'
Init arduino done ---------------

[lostbard]

ok - just verifying. Let me know on the .cc one - hopefully it shows the same issues as the serialport, so we have a minimal(ish) example of code to look at.

[EkpuzC]

For the .cc one, I don't see a file I can rename and test.

[lostbard]

I guess i forgot to attach :) testserial1.txt

[lostbard]

I did manage to find a redboard and ran it in linux multiple times trying to get it to fail but could not get it to . So it may just be a mac thing, which makes it harder to find since I cant duplicate.

looking to /var/log/messages when pluggin it in for me:

Mar 24 16:01:38 fedora kernel: usb 2-1.5: new full-speed USB device number 19 using ehci-pci
Mar 24 16:01:38 fedora kernel: usb 2-1.5: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
Mar 24 16:01:38 fedora kernel: usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 24 16:01:38 fedora kernel: usb 2-1.5: Product: FT231X USB UART
Mar 24 16:01:38 fedora kernel: usb 2-1.5: Manufacturer: FTDI
Mar 24 16:01:38 fedora kernel: usb 2-1.5: SerialNumber: D30DV3LO
Mar 24 16:01:38 fedora kernel: ftdi_sio 2-1.5:1.0: FTDI USB Serial Device converter detected
Mar 24 16:01:38 fedora kernel: usb 2-1.5: Detected FT-X
Mar 24 16:01:38 fedora kernel: usb 2-1.5: FTDI USB Serial Device converter now attached to ttyUSB0

[EkpuzC]

Testing with Elegoo board:

>> testserial1
<< 165 0 1 0
>> 165 0 1 7
>> 30 149 15 0 50 5 0
board = 0 volref=5.000000 libs=5
<< 165 0 8 1 0
>> 165 0 8 5
>> 0 67 111 114 101
lib 0 'Core'
<< 165 0 8 1 1
>> 165 0 8 4
>> 1 73 50 67
lib 1 'I2C'
<< 165 0 8 1 2
>> 165 0 8 4
>> 2 83 80 73
lib 2 'SPI'
<< 165 0 8 1 3
>> 165 0 8 6
>> 3 83 101 114 118 111
lib 3 'Servo'
<< 165 0 8 1 4
>> 165 0 8 14
>> 4 83 104 105 102 116 82 101 103 105 115 116 101 114
lib 4 'ShiftRegister'
>>

Re: working in Linux...I have suspected that it is something peculiar to the Mac, and recognize that it is extra difficult to debug when you can't replicate the issue. I think I've said before that I really hope I'm not just doing something dumb and wasting a bunch of your time. I feel at least reasonably hopeful that that is NOT the case since I can show that some Arduino compatible boards work, while others don't. It looks like your board is an FTDI one which is the specific chip type that I see issues with. I'm not a Mac user, but it seems like the common wisdom is that usually drivers don't have to be fiddled with, but maybe in this case they do. I can try to research of there might be some alternate FTDI driver that I could try.

[lostbard]

So the oct program appears to work fine as well ?

There are several posts around about ftdi drivers on the mac. Not sure if they are still relanatnt, but I would think it would display same behavior with python as octave as whatever else is used.

[lostbard]

Maybe i see something. DOes this one break the same as using octave serial port ?

(new function name testserial2)

testserial2.txt

[EkpuzC]

Here is the output from testserial2:

>> testserial2
test serial 2
<< 165 0 1 0
>> 165 0 1 7
>> 30 149 15 0 50 5 0
board = 0 volref=5.000000 libs=5
<< 165 0 8 1 0
>> 165 0 8 5
>> 0 67 111 114 101
lib 0 'Core'
<< 165 0 8 1 1
>> 165 0 8 4
>> 1 73 50 67
lib 1 'I2C'
<< 165 0 8 1 2
>> 165 0 8 4
>> 2 83 80 73
lib 2 'SPI'
<< 165 0 8 1 3
>> 165 0 8 6
>> 3 83 101 114 118 111
lib 3 'Servo'
<< 165 0 8 1 4
>> 165 0 8 14
>> 4 83 104 105 102 116 82 101 103 105 115 116 101 114
lib 4 'ShiftRegister'
>>

[lostbard]

ok - not sure what to try next, as I believe the testserial2 should be the equvalent to what already doing in instrument control so should behave the same

[lostbard]

i guess that leaves some intermittant timing issue .. with it running sligh;y slower under octave than it would with a oct file

[lostbard]

ANother .m file to try testarduinoconnect3.txt

[EkpuzC]

Looks like it works fine. First the Elegoo board:

>> testarduinoconnect3

port = /dev/tty.usbmodem14201
baud = 9600
readtimeout = 0.5000
Init arduino 3 --------------------
a =

  Serial Port Object Serial-/dev/tty.usbmodem14201
    Port:     /dev/tty.usbmodem14201
    BaudRate: 9600
    Parity:   None
    DataBits: 8
    StopBits: 1
    Timeout:  0.5

cdata = [](0x0)
>> 165 0 1 0
<< 165 0 1 7
<< 30 149 15 0 50 5 0
boardid = 0
voltref = 5
numlib = 5
>> 165 0 8 1 0
<< 165 0 8 5
<< 0 67 111 114 101
lib: core
>> 165 0 8 1 1
<< 165 0 8 4
<< 1 73 50 67
lib: i2c
>> 165 0 8 1 2
<< 165 0 8 4
<< 2 83 80 73
lib: spi
>> 165 0 8 1 3
<< 165 0 8 6
<< 3 83 101 114 118 111
lib: servo
>> 165 0 8 1 4
<< 165 0 8 14
<< 4 83 104 105 102 116 82 101 103 105 115 116 101 114
lib: shiftregister
Init arduino done ---------------
>>

And here is the older redboard:

>> testarduinoconnect3

port = /dev/tty.usbmodem14201
port = /dev/tty.usbserial-DN03GDV8
baud = 9600
readtimeout = 0.5000
Init arduino 3 --------------------
a =

  Serial Port Object Serial-/dev/tty.usbserial-DN03GDV8
    Port:     /dev/tty.usbserial-DN03GDV8
    BaudRate: 9600
    Parity:   None
    DataBits: 8
    StopBits: 1
    Timeout:  0.5

cdata = [](0x0)
>> 165 0 1 0
<< 165 0 1 7
<< 30 149 15 0 50 5 0
boardid = 0
voltref = 5
numlib = 5
>> 165 0 8 1 0
<< 165 0 8 5
<< 0 67 111 114 101
lib: core
>> 165 0 8 1 1
<< 165 0 8 4
<< 1 73 50 67
lib: i2c
>> 165 0 8 1 2
<< 165 0 8 4
<< 2 83 80 73
lib: spi
>> 165 0 8 1 3
<< 165 0 8 6
<< 3 83 101 114 118 111
lib: servo
>> 165 0 8 1 4
<< 165 0 8 14
<< 4 83 104 105 102 116 82 101 103 105 115 116 101 114
lib: shiftregister
Init arduino done ---------------
>>

[lostbard]

ok ... just to verify it is still the case, testarduinoconnect2 still fails occasionally, but testarduinoconnect3 appears to always work ?

[EkpuzC]

I just tested them both, and testarduinoconnect2 usually fails right away but occasionally has some successful reads before failure, while testarduinoconnect3 appears to always work.

I think I remember you testing if timeout=10 would cause a wait of 10 seconds, but I've reading through the documentation and source code for instrument-control and am seeing references to the timeout vaue being tenths of a second (with a max of 255 corresponding to 25.5 seconds). I realize the value could have different meanings in different contexts, but I didn't see any code that would translate between seconds and tenths. As I've shared before, I'm rusty on OOP and have never used it in Octave so I may just not be looking at the right place.

[lostbard]

serialport uses timeout in seconds, serial uses timeout in 10th of a second. In reality serialport waits far less than the timeout but does it X times to mimic the actual speicified timeout - part of the reason fo that is so that theuser can ctrl-c to exit out of waiting forever etc.

So if the testarduinoconnect3 always works, I think we have narrowed it down to two possible things.

Ill send a version 4 that rules out one of them. When it still doesnt fail, it must be other one causing it? :)

[lostbard]

version 4 .m file testarduinoconnect4.txt

[EkpuzC]

Version 4 fails consistently:

>> testarduinoconnect4

port = /dev/tty.usbmodem14201
baud = 9600
readtimeout = 0.5000
Init arduino 4 --------------------
a =

  Serial Port Object Serial-/dev/tty.usbmodem14201
    Port:     /dev/tty.usbmodem14201
    BaudRate: 9600
    Parity:   None
    DataBits: 8
    StopBits: 1
    Timeout:  0.5

cdata = [](0x0)
>> 165 0 1 0
<<

If I'm interpretting what you've done correctly, it looks like there are two set(a, "timeout", xx); that might be the issue. I investigated more by commenting out one at a time and it looks like the one in send_cmd() is the culprit. If it is commented out the code runs without failure.

I experimented some more and it strikes me as very strange the way it works (although, again, it may be my lack of understanding). If I comment out that set(a,"timeout", rt) line the testarduinoconnect4.m works fine. I tried to read the value of the timeout property to see what it was at that point. Interestingly, and maybe this is evidence of my not understanding, I had to do snd_cmd_rt = get(a, "Timeout") (with a capital T) as snd_cmd_rt=get(a, "timeout") did not recognize it as a property. The value that we get at that point is 0.1. If I set timeout to 0.1 it fails. Perhaps "Timeout" and "timeout" are different properties and this isn't surprising.

Anyway, it seems like at least with the test code you've narrowed it down to a single line that can cause a failure. Hopefully that will lead to an understanding of what is going on and how to fix it in the package code.

BTW, I confirmed that the new Redboard (the one that has not had problems) is insensitive to the presence or absence of that line and still always works. The old Redboard shows the same behavior as the Elegoo (it works without that line, and fails with it).

[lostbard]

There is a set and get function provided in @octave_serialport in instrument-control. The reason 'timeout' works in set but must be 'Timeout' in get is only because we lowercase the value sent in set before checking it exists, but do not for get.

Ie: set(a, 'timeout', 10) get(a, 'Timeout') -> returns 10 set(a, 'Timeout', 20) get(a, 'Timeout') -> returns 20

It should perhaps be consistent, but I dont think is the issue.

My assumption would be that either something isnt right when it sets the timeout in instrument control, OR on configuring the port, it loses the data that may already be waiting.

What happens if we move the timeout to before the write?

testarduinoconnect5.txt

[EkpuzC]

Using testarduinoconnect5.m, it looks like it works consistently:

>> testarduinoconnect5

port = /dev/tty.usbmodem14201
baud = 9600
readtimeout = 0.5000
Init arduino 5 --------------------
a =

  Serial Port Object Serial-/dev/tty.usbmodem14201
    Port:     /dev/tty.usbmodem14201
    BaudRate: 9600
    Parity:   None
    DataBits: 8
    StopBits: 1
    Timeout:  0.5

cdata = [](0x0)
>> 165 0 1 0
<< 165 0 1 7
<< 30 149 15 0 50 5 0
boardid = 0
voltref = 5
numlib = 5
>> 165 0 8 1 0
<< 165 0 8 5
<< 0 67 111 114 101
lib: core
>> 165 0 8 1 1
<< 165 0 8 4
<< 1 73 50 67
lib: i2c
>> 165 0 8 1 2
<< 165 0 8 4
<< 2 83 80 73
lib: spi
>> 165 0 8 1 3
<< 165 0 8 6
<< 3 83 101 114 118 111
lib: servo
>> 165 0 8 1 4
<< 165 0 8 14
<< 4 83 104 105 102 116 82 101 103 105 115 116 101 114
lib: shiftregister
Init arduino done ---------------
>>

[lostbard]

now the only issue is that the arduino toolkit initialize already has the timeout set before the write already :)

One more thing to verify - is instrument control the modified one or the pkg install -forge one?

[EkpuzC]

I think the I-C is the modified one, but I'm not absolutely positive. I know as we've been going through this process I've reinstalled some things and I don't remember for sure if I did that after the modified one. Is there something I can check to make sure? Should I definitely be using one or the other? It isn't that big of a deal to try them both, but I imagine it might be useful for you to know which I've been using recently.

[lostbard]

Its probally easiest to reinstall the released one via pkg install -forge instrument-control and seeing if it still works.

I am planing on releasing a new instrument control in the next day or so as well, but it does not have the change that the modified one has, but has a couple of other changes that may help.

[lostbard]

Any early release copy of the next version instrument-control-0.9.3.tar.gz

[EkpuzC]

I think it works!! With the Elegoo board:

>> a=arduino('/dev/tty.usbmodem14201')
a =

  arduino object with fields of:
            port = /dev/tty.usbmodem14201
           board = uno
       libraries = {
              i2c
              spi
              servo
              shiftregister
        }
        availablepins = {
              d0 - d13
              a0 - a5
        }

>> writeDigitalPin(a,'D13',1)
>> writeDigitalPin(a,'D13',0)
>> writeDigitalPin(a,'D13',1)
>> writeDigitalPin(a,'D13',0)
>> pkg list
Package Name        | Version | Installation directory
--------------------+---------+-----------------------
           arduino *|  0.12.1 | /Users/c.z/.local/share/octave/api-v59/packages/arduino-0.12.1
instrument-control *|   0.9.3 | /Users/c.z/.local/share/octave/api-v59/packages/instrument-control-0.9.3
>>

I also was tested the old (FTDI) redboard and the new (CH340) redboard and they all worked as expected.

I did have a little trouble installing Instrument Control (both from the current version and your development version). I'm probably doing something wrong but I would get errors (not just warnings) and the packages wouldn't be present (or if they were they just didn't work). Installing immediately after closing and reopening Octave I think is what made it work. A few times I got errors about GPIB not being supported by my hardware. I did a few things recommended as a workaround but then couldn't find the makefile to edit so I gave up and stumbled on the installing on a newly opened instance.

I don't think these issues were responsible for it not working before as I was able to install the libraries without error and serialport seemed to be working fine. I'm also pretty sure that I was able to re-install the original I-C and verify that the various versions of testarduinoconnect worked (or not) as before, and still couldn't make an arduino object.

Anyway, I'm hopeful that you fixed the issue and am curious: Are you confident you know what did it, or if you think we lucked out a bit?

If you would like for me to do any more testing to pin down anything, let me know.

Thanks so much for all of your effort! I use Octave and the arduino package in an engineering class and while most students seem to have Windows machines, I am hopeful the occasional Mac user will now be less likely to run into problems.

[lostbard]

Confident ... no. I believe for whatever reason, when setting the timeout, it is possible it is clearing out the data that is already there. So it ends up timing out because there is no new data.

It shouldn't clear the data out on setting the serial port parameters, but to be fair the option to set parameters doesn't say it will not, so may be open to interpretation for driver implementation.

Anyway, the timeout setting was setting new serial parameters, even in the cases where it didn't need to (as nothing was really going to change internally). The new code tries to be smarter on this and not change the actual port on timeout changes when it doesn't really have anything to change.

It doesn't seem to be a problem in linux (where I mainly run it)

For the trouble installing, can you provide logs or output from that fails? In theory, for most things, it should just detect the missing library, show a warning and not install that part of instrument control, but it is possible something isn't fully correct and it tries regardless.

[lostbard]

btw. Thanks for providing your time to test possible changes. It is often difficult to work out bugs - especially when they are on different OSs than those used by the developer, without the help of the user.

[lostbard]

Closing as fixed, bug assumed to be an issue with instrument-control < 0.9.3

[EkpuzC]

I'm happy to help and appreciate all the work that you and others have put into the Octave ecosystem.