TCIgor

И вот, кстати, причина, по которой "максимально развёрнутая информация" приводит к более частому решению проблемы. Если сказать "какой-то мерседес", то найти было бы сложнее. Даже имея наименование модели, пришлось проверить с десяток вариантов. Проблемная модель находится в ветке AutoData. Эта часть БД действительно, автоматически переносится из данных, предоставляемых AutoData. Будем смотреть, проблема ли это с переносом или с исходными данными. Еще раз спасибо.

Спасибо! Посмотрим, починим. Был бы признателен услышать какие именно глюки и как они проявляются. Собственно, если кто-то присылает нам развёрнутую информацию о какой-то проблеме, мы ... стараемся починить. Конечно, есть много "если": если это действительно проблема, если мы можем это повторить, и если её "можно починить".

Сильной разницы не будет. Это устраняется при компенсации. Главное чтобы было всё надежно и жестко закреплено и не болталось.

Если задние мишени "моргают желтым", это означает нестабильность их положения (в реальности, или в связи с освещенностью). Надо смотреть. Рекомендую ещё раз обратиться в сервисную службу. То, что можно попробовать посмотреть самому, описано здесь:

Так быть не должно в любом случае, даже если калибровки "кривые". В случае, если что-то ослабляется в ходе регулировки, конечно, значения будут меняться если обратно всё затянуть, но, если абсолютно *ничего* не делать при переходе из "измерения" в "регулировку", то значения в отчете не должны отличаться от значений в регулировке. А подъёмник Вы случаем не поднимаете перед регулировкой? Также, чтобы избежать возможных недоразумений, предложил бы отключить опцию "нормализовать переднее левое/правое схождение в отчете". Для более "красивого" отчета, она просто "доворачивает руль" виртуаль

Здравствуйте. Варианта, действительно, три: - Двухкамерный; - Двухкамерный с лифтом, точнее в нашем случае - с поворотным механизмом. Балка поворачивается, а не опускается вверх-вниз; - Четырехкамерный. Двухкамерный. Преимущества: Цена; Проще в калибровке; В два раза меньше камер, т.е. в разделе "камеры" в два раза меньше чему ломаться; Поворотный стенд: может видеть от пола. Недостатки: Менее дальнобойный. Теоретически 4хкамерный увидит дальше, но с другой стороны, обсуждаемые выше длинобазные Газели, может увидеть и один и д

Добрый день. Хоть официально мы и не поддерживаем колесные базы длиной более 4м - никаких технических причин, по которым не будет измеряться нет. Главное чтобы мишени ПО "увидело". Если сомневаетесь - можете просто отставить мишень на расстояние колесной базы (плюс расстояние прокатки) и посмотреть - ловятся ли стабильно мишени на этом расстоянии.

Это связано с БД. Автодата, видимо, значительно поменялась. Мы при разработке столкнулись с такой дилеммой: если в режиме Поиск Клиента использовать "спецификации" из предыдущей регулировки, то, если, предположим, в БД были ошибочные значения - то даже НОВАЯ регулировка подтянет "старые данные из отчета", несмотря на то, что в БД новые данные. Ну и к тому же, что делать с иллюстрациями, или еще хуже - Мерседесами с выбором из дополнительных таблиц? Потенциальная ошибка. Поэтому мы тянем спецификации принципиально только из БД. Если в старом отчете ссылка на несуществующую запись в БД - кнопка

Обратились еще клиенты с этой же проблемой на свежем обновлении. Видимо, что-то все-таки изменилось. Будем копать.

База данных лежит на сайте отдельно. Можете обновлять только её. Есть теория, что это связано с каким-нибудь обновлением Windows, а не с ПО. Возможно, Windows "обновило драйвер" само но как-то неудачно. Спецификации разные. Если бы они не зависели от выбранной строки, мы бы и не просили её выбирать 🙂 . Насчет инклинометра - пока ничего не могу сказать. В планах был.

Изменений не было с 2017 года. Это может быть только драйвер.

А до этого проблем не было? Только с обновлением появилось? Если да - то посмотрим. Может, что-то все-таки изменилось с нашей стороны. Это, конечно, виноват драйвер интеловский. А что делать! Часто какие-то такие мелкие графические пакости появляются из ниоткуда. То одно драйверу не нравится то другое. Приходится методом проб и ошибок выяснять что ему не нравится, и менять. Хорошо хоть пока не было взаимоисключающих "поправок" (в том смысле, чтобы одно исправление чинило одного производителя видеокарт и одновременно "ломало" другого). Есть, конечно, и радикальное решение. Поставить отдел

Это уже неоднократно освещалось на форуме (где-то). Во времена кордовых и CCD стендов они писали значение "погрешности" как значение, на которое "развал по захвату" (немного некорректно, но не имеет большого значение) смещен относительно "развала по колесу". То есть насколько неровно был установлен захват. Для 3D стендов (по крайней мере ТехноВектор) нет разницы, насколько неровно установлен захват (разница может возникнуть, если возникнет еще и дополнительное смещение, а также некоторые нереалистичные варианты, например, если установить захват "криво" на 90 градусов или больше, потому ч

Это настройка в ПО. Настройки -> Обслуживание -> Дополнительные параметры -> Автоматический переход в измерение при удовлетворительных результатах компенсации прокаткой. Если захват не сдвигается в ходе компенсации, погрешности и не будет. Для получения оси вращения колеса нет никакой разницы (в разумных пределах) как установлен захват. Главное, чтобы не произошло какого-то "случайного движения/смещения" в ходе компенсации, чтобы ось вращения определилась корректно.

Да, были изменения в процедуре компенсации. Проверяем. Приоритет наивысший. Если найдем какие-то проблемы - выпустим срочное обновление.