It looks like the issue might be related to a compatibility difference between the two firmware revisions. In your case, the unit with firmware version 258 seems to start scanning normally but then runs into an operation timeout, whereas the unit with firmware version 257 works without issue in ARC-which means the ARC RPLidar skill (and its underlying SDK) may not yet be fully compatible with firmware revision 258.

Below are a few troubleshooting steps and recommendations:

1. Confirm Firmware Differences
   The functional unit (firmware 257) and the malfunctioning unit (firmware 258) share the same hardware profile (Model:65, Hardware Version:18) but the newer firmware 258 might have modified timing or communication parameters.
   Since RoboStudio shows everything working as expected for firmware 258, it seems the sensor itself isn’t defective-but rather the ARC RPLidar skill (using the Slamtec SDK 2.1.0) may be expecting behavior aligned with firmware 257.

2. Adjust Timeout Settings or Parameters (If Available)
   Check the configuration settings in the ARC RPLidar skill. Although the timeout is set to 2000ms by default in ARC’s code, it might be worth exploring if there are settings (via the configuration or an advanced option) to tweak the timeout or sample rate parameters to accommodate the behavior of firmware 258. Look for any documentation or release notes on firmware version 258 that might indicate changes in scan data rates or latency.

3. Firmware Downgrade (If Possible)
   If your project can afford using the older revision (firmware 257), consider downgrading the malfunctioning unit to firmware 257 since that version is known to work flawlessly in ARC in your setup. Be sure to review the instructions for downgrading (or re-flashing) firmware if you choose to take this path.

4. Monitor Logs and Behavior
   In ARC, keep an eye on the log details and note exactly when the timeout occurs. Sometimes additional clues in the output may help pinpoint if the ARC skill is missing an updated command sequence or if there’s an unexpected delay coming from the device. Since the exception shows that it times out at the scheduler event in MainForm.cs, it indicates that the expected scan data wasn’t received as quickly as ARC anticipated.

5. ARC and RPLidar Skill Updates
   It is possible that a future update to the ARC RPLidar robot skill (or SDK) will add necessary support for firmware 258. In the meantime, if you’re comfortable with DIY fixes, you might check if there’s an option to create a custom robot skill (see Synthiam’s Create robot skill documentation: Create robot skill Overview) to adjust the parameters as needed.

6. Follow-Up Questions
   Have you had a chance to review any release or update notes from either Slamtec or the ARC RPLidar skill regarding firmware 258?
   Would downgrading the firmware be a viable option for your project if no immediate workaround in ARC is available?

Based on what you’ve shared, the differences in firmware (257 vs. 258) are very likely the cause. I recommend testing with a firmware downgrade if possible, or keeping an eye on ARC updates that may add full compatibility with firmware 258.

Let me know if you have further questions or need more guidance on any specific step.

My guess is the USB hub is saturated, especially if both devices are connected. The RP LiDAR Robot Studio app is more forgiving for timeouts because it isn't running in high-profile mode, where timing resolution is critical. The rp lidar robot skill would time out if there is missing data - which would only happen with one of these:

1. Physical loose connection from the rp lidar to the USB uart converter

2. USB hub saturation. Remember, your computer may have 2 or 3 or 10 USB ports, but internally, there are a few hubs. You can view what's connected through the Windows device manager. Although I believe sysinternals has a good USB program for viewing ports but I can't recall what it's called

If you're diagnosing #2, disconnect all other RP lidars and stuff that isn't being used (i.e., cameras, etc). Find out exactly how to get that lidar working and note the necessary changes to make it happen.

Also, adding a third option to DJ's list would be important. USB ports have a limitation on current. Specifically, USB ports are only designed for solid-state devices, not DC motors. The Lidar uses a DC motor to spin the sensor, which requires higher current than the USB specification. If you use multiple Lidars, or the lidar requires a bit more current, it could exceed the current maximum. A powered USB hub would therefore be necessary. USB hubs should be connected via USB-C, if possible; otherwise, they should be connected via USB 3.

Just to clarify, I always tested only one RPLidar at a time. The problematic unit (firmware 258) was connected by itself, using a single USB-UART adapter, with no other devices attached. I repeated the test on three different PCs (both Windows 10 and 11), and even tried a second USB adapter. Only the unit with firmware 257 works reliably in ARC. On my robot chassis  I unplugged the good rplidar and I connected the new one. I used the same usb connector, don't change anything else. Just a reboot of the sbc. one rplidar for one chassis.

Thanks for the additional information. We will send these details to the manufacturer for feedback. The robot skill is built around their library, so we will need to see what they come back with. Perhaps there is an update to their library - although, the communication should be the same.

for info: here is the firmware version coming from robostudio.  rplidar-c1 working ok is version is 1.1 , not working rplidar-c1  is version 1.2.

To ensure proper power delivery, I’ve tested the unit with a powered USB hub, but the problem persists. Additionally, the RPLIDAR skill in ARC does not mention any version-specific constraints, so I believe the skill should be able to handle the hardware updates seamlessly, even if Slamtec has made changes to the RPLIDAR.

After experiencing this issue with the first unit, I purchased a second RPLIDAR C1, expecting the hardware to function properly. Unfortunately, the issue persists with both units.

I would appreciate any insight on whether there have been any updates or changes needed for the ARC skill to work with newer versions of the RPLIDAR C1. If not, I am considering moving to the RPLIDAR A1 and would like to confirm whether it works reliably with the current ARC skill.

Thank you for your time, and I look forward to your support in resolving this issue.

We understand that a challenge with Slamtec's product can be frustrating. However, Synthiam is unable to make changes to Slamtec's products because Slamtec is its own company. We have notified them of the details of your challenge and are now awaiting a response or action.

Synthiam ARC is a platform that loads robot skills - think of it as Microsoft Windows loading applications. The robot skill is Slamtec's library; therefore, we must be patient while they identify a solution or workaround.

We have a question because we do not understand one of your comments. Can you add more details so it can be better understood?

Quote:

for info: here is the firmware version coming from robostudio. rplidar-c1 working ok is version is 1.1 , not working rplidar-c1 is version 1.2.

thanks for your response. the firmware version read by ARC is 257 /258. I am not sure Slamtec knows about these numbers . That's why I sent you the version from robostudio which is 1.1/1.2.  it seems to be the official version of slamtec

Have you tried the latest update to the RP Lidar robot skill?

It is very interesting that their libraries and applications return different values for the firmware. Because ARC doesn’t provide firmware version numbers for the RP Lidar. ARC functions like an operating system (similar to Microsoft Windows), and the RP Lidar robot skill is developed by the hardware manufacturer using their own SDK, library, or API. If you see firmware values such as 257 and 258, those are raw values returned directly by their library. Their RoboStudio software likely translates these values into something more user-friendly, while the robot skill returns them as-is. We could not guess their reasoning for having differing representations of the firmware.

Since Synthiam doesn't develop the RP Lidar’s SDK or robot skill, we can’t speak to the manufacturer’s reasoning for returning different firmware values.

That said, the latest update to the RP Lidar robot skill appears to include several improvements-one of which addresses timeout behavior, which relates to the issue you previously encountered. We recommend installing the latest version of the RP Lidar robot skill and reviewing the new configuration options to see if they help resolve the problem.

Indeed, the latest update solved the problem - the 'new' RPLIDAR with firmware version 258 now works. I retested with the older RPLIDAR (firmware version 257), and it works too. I don't know what you did, but everything works fine now. The RPLIDAR skill v26 has a new feature: 'force scan' or 'use typical scan.' In my case, 'typical scan' is being used. The Better Navigator also works with both versions.

That’s wonderful to hear. The resolution must have been related to their new Timeout option. Looking at their sdk, we guess their default was 2000 ms and the new default setting is 5000. That must provide more time for the motor to spin to speed without timing out.

Regarding the firmware, I know what you guys are seeing. I took a look at their library and they return the firmware version as an unsigned 16 bit int...

typedef struct _sl_lidar_response_device_info_t
{
    sl_u8   model;
    sl_u16  firmware_version;
    sl_u8   hardware_version;
    sl_u8   serialnum[16];
} __attribute__((packed)) sl_lidar_response_device_info_t;

So it looks like the 16 bit unsigned int is both parts of the decimal firmware. It can be wrapped such as...

uint16_t fw = devinfo.firmware_version;
int fw_major = (fw >> 8) & 0xFF;
int fw_minor = fw & 0xFF;

std::cout << "Firmware Version: " << fw_major << "." << fw_minor << std::endl;

Okay - we can display that version in the robot skill formatted as major/minor. That will be a bit of a hack because they aren't doing that in their robot skill for some reason. It's probably something they overlooked.