Engineer Kit 1 SPI not interfacing correctly with Engineer App

I just finished building the SPI robot and am having trouble getting it to work with the phone app. It behaves the same with both an Android phone and an iPhone.

The robot connects and the motor mode and offset mode works fine. The remote, music and clap mode do not work. The mode button on the CM550 blinks white and nothing happens when a button is pressed (on the phone app).

The robot works properly with version 3.1.4 and 3.1.5 of the Roboplus 3.0 PC app. It synchs and all motions work correctly.

It seems like it is something with the Task code or the Engineer app itself. I have tried it with another CM550 and the same issues occur.

I have reset all of the cables. The CM550s and the servos were all checked with the Manager app (firmware versions, setting and alignment)

Does anyone have any ideas on what to try? Has anyone else experienced this? Appreciate any help.

Note to Add:
No RC is working - not just the RC inside the Engineer App. I did a simple program with Task to test with the RC inside the debug area - and the robot shows connected, program is running, RC signal is sent - but robot does not move.

A simple program that just executes three motions without RC does work.

@Blackbolt
Regarding the RC issue, the CM-550 has three options for setting the Remote Port (Address 43):

  1. When set to 0, the CM-550 uses the Embedded BLE, i.e., on the Desktop side you need to use whatever COM Port corresponding to the USB BT-410 Dongle.
  2. When set to 1, the CM-550 uses whatever BT receiver connected to its UART port (4-pin connector).
  3. When set to 2, the CM-550 is using the USB port, i.e., plain USB cable.

Please use the MANAGER tool to check on this Address 43 or use a TASK statement to specify which COMM option is actually used for this Remote Port Address 43. Hopefully, it may be only a mismatch issue between actual comm. hardware used for RC and the actual setting for Address 43.

I had found that this issue is “independent” of the actual hardware/port that had been used to download the TASK code in the first place! Meaning that for example, you can download your TASK code via USB BT-410 Dongle (i.e., using CM-550’s BLE), but at run time, if your TASK code is expecting Remocon packets to come through the USB Port or the UART Port (BT-210 for example). Then, if your TASK 3 Virtual RC-100 Tool is still connected to the BLE port, all your UDLR123456 buttons would seem not to work at all. This had happened to me several times in the past! :grin:

Thanks for the idea to try! The CM550 Address 43 is set to “0.” I used the BT410 and CM550 BLE to download the programs. I have not designated a communication port in my task code so I assume that the same port(connection) would work with the Virtual tool?

The same code worked fine on a different robot…

@Blackbolt
If the same TASK code works on another CM-550, then I would suggest refreshing the firmware on the “suspect” Embedded BLE using the MANAGER 2 tool (using USB cable):

  1. Go to ALL PRODUCTS and choose “BLE(CM-550)” towards the bottom of the list

  2. Then select “Firmware Recovery”

then follow on-screen instructions

After the BLE firmware recovery, hopefully everything should be functional again.

I have refreshed the cm550. I also rechecked/tested all of the servos and cables. I haven’t tried using the UART port to use the actual RC, rather than trying to use the virtual one, and the phone and eng app ones.

Not sure what I will try next….

Update on SPI Demo Code and Engineer App:

I got the SPI demo code working. I decided that there was something about the motion file that was the issue. When I was using a Windows VM through Parallels on my Mac the motion file was slow to load and then finish. I rebooted my Mac to Bootcamp - meaning that I was running a Windows machine - not a VM. When downloading both the Task and Motion files it was much faster and no hanging at the end.

Now it works. I think that the motion file was not loading properly. There isn’t a problem with smaller files, which explains why I had not noticed previously. (AND this explains why Dr. R was sporadic with movement a few months ago. At some point I will rebuild him and try loading files from Bootcamp Windows and see if it works better.)

This week I will try smaller task files using the delivered motion file that has been downloaded in Bootcamp and see if my theory proves out.

I have been using Robotis products for several years. There are challenges when using Robotis products with a Mac. Some things work using a Windows VM with Parallels, but as this example illustrates, you can spend time trouble-shooting things that don’t happen on a stand-alone windows machine. In addition, the iPad and iPhone apps do not have the same functionality as an Android phone - and have not been updated in 2 years.

I have an Intel Mac. Parallels on a newer Mac with the M1 chip can only use the ARM version of Windows - and the Robotis applications will not work.

Thanks Roboteer for your help.

1 Like

Thanks for being the “Mac Expert” for this Community!