|
There was an error in the conditions of the Upgrade Support Service in the previous version of this release note sent out earlier today. This has been corrected in this version of the release note.
We apologize for any confusion that may have led to.
Target audience
We recommend this software upgrade for MiR robot users who have already migrated to SW 3.x and have experienced any of the issues described, or who want to migrate from SW 2.x to 3.x.
Description
This software upgrade resolves several issues regarding MiR products.
If you have not upgraded from software 2.x to 3.x yet, MiR still provides help with your transition.
To help you seamlessly transition to MiR software 3.x and make the most of its benefits, we offer Upgrade Support Service. This service is designed to minimize site downtime and reduce the risk of unforeseen issues during the upgrade process. You will get assistance from our team of application engineers who have in-depth knowledge of the migration process. MiR Upgrade Support Service consists of two steps: Step 1 is a site assessment and recommendations from MiR, and Step 2 is optional on-site support from MiR.
Until June 28 2024, we offer you Step 1 of the Upgrade Support Service for free when you buy and add new robot(s) to your MiR Fleet. This can help you decide the strategy of migration from software 2.x to 3.x. Contact your MiR representative for more information.
For more information on how to upgrade and migrate to software 3.x—see MiR Migration Guide 2.x to 3.x.
Issues solved
- Robot stopped docking to a marker if Protective stop was activated (MIRS-15597)
Sometimes, if a robot was docking to a marker and entered a Protective stop on its way, where the robot could no longer see the marker, the robot would stop docking to the marker and throw an error. This issue has now been solved.
- Robot moved in opposite direction when undocking from a marker (MIRS-15612)
Sometimes, the robot would perform a short motion in the opposite direction when it was undocking from a marker. This issue has now been solved.
- Robot randomly requested Limit-robots zones (MIRS-15543)
Sometimes, if a robot was docking to a marker inside a Limit-robots zone, and another Limit-robots zone was added around the same area, the robot would randomly request different Limit-robots zones. This issue has now been solved.
- High memory usage on MiR Fleet server (MIRS-15539)
In some cases, the memory usage on MiR Fleet servers would gradually rise, making MiR Fleet slow or unresponsive. This issue has now been solved.
- I/O module action moved place in mission order (NEX-3604)
Sometimes, if you were creating or editing a mission, added a Set and reset I/O, a Set output, or a Wait for input action, then set the Timeout to zero and moved one of these actions to a different place in the mission order, the action would move to the top or the bottom of the mission instead and the settings in the action were not saved. This issue has now been solved.
- MiR Fleet with different robot types caused blockage and distance confusion (NEX-3601)
Sometimes, if you had different types of robots in , it would increase the risk of incorrect robot tracking, where a robot would be blocked by other robots that were not there. If a robot tracked another robot's front or back, it would incorrectly estimate the other robot to be closer than it really was. This issue has now been solved.
- Robots continued to drive after losing connection to the power board (MIRS-15514)
In rare cases, if the connection to the power board was lost for a longer period of time while the robot was driving, the robot would continue driving. The safety system of the robot was not affected by the issue, so robots would stop for obstacles. This would manifest itself in inaccurate driving patterns and failure to complete missions. This issue has now been solved.
- All recorded data disappeared from map when eraser was used to edit map (MIRS-15484)
Sometimes, if you were editing a map and erasing something on the map using the eraser tool under Walls and floors, and saved the map, all recorded data would disappear from the map. This issue has now been solved.
- Robot changed localization after Emergency stop (MIRS-15483)
Sometimes, when the robot skidded after an Emergency stop, it would incorrectly reuse the position of a previous skid, resulting in the robot jumping to a random place on the map. This issue has now been solved.
- Robot could not send email to an SMTP server that did not require authentication (NEX-3360)
Sometimes, if you attempted to send an email to an SMTP server from the robot through a mission where Authentication required was disabled under System > Settings > Email configuration, the email was not sent because it tried to authenticate on a server that could not handle it. This issue has now been solved.
- MiR250 Hook feature was disabled after upgrade to software version 3.x (NEX-2287)
Sometimes, if you upgraded your MiR250 Hook from software version 2.x to 3.x, the hook feature was disabled after the upgrade. This issue has now been solved.
- Robot failed to set footprint during mission (MIRS-15391)
On rare occasions, the robot reported an error indicating that the robot footprint could not be found when running a mission. This lead to the mission failing. This issue has now been solved.
|
Comments
0 comments
Please sign in to leave a comment.