cnc-club.ru

solo писал(а):А че у меня такой проблема меня тоже это все удивляет

UAVpilot переключал из своего скетча ,так что с платой у тебя все в порядке скорей всего...
а косяк где то в коде(кто то криворукий написал ) - в работе его еще никто не проверял (может aftaev?)

провел небольшое тестирование
На выход ардуино прицепил через транзисторный ключ релюшку на вывод 50 в хеле соединил
net digout100 motion.digital-out-00 arduino.Dout3-50
, контакты реле замыкаю вход ардуино 20 , которы отслеживается по Ж38.2 в хеле соединил
net 2digin20 arduino.Din1-20 gladevcp.hal_led1 motion.digital-in-00 motion.probe-input
по данной схеме я так понимаю у меня проходит двойной обмен по модбусу
запускаю ж код
G0X0
M64 P00 (посылаем на цифровой выход 50 ардуино "1" на реле срабатывает)
G38.2 F100 X100 (еду до сработки контактов реле)
G4P0.2
M65 P00
M2
По перемещению по оси Х оцениваю скорость модбуса
результат минимальное время (перемещение ) 0.113 мах 0.702
Может у кого то есть предложение на счет другого Ж кода или как то по другому провести тест.

какие из показателей загрузки LCNC могут влиять на скорость по модбусу , хочется разброс уменьшить хотя бы в 2 раза

может у меня все таки немного кривовата ардуина .
У мена светодиоды RX TX на плате горят интенсивно но не очень равномерно - мерцают , что наверное сигнализирует о не равномерном обмене по модбус.

Может попробовать оценить быстродействие подключив модбас просто к терминальной программе?
Сразу станет видно где косяк с быстродействием. Скорее всего проблема с ЕМС, и неразрешимая.

Мне бы если бы объяснили по доступней чего куда втыкать на какие пимпочки жимить а то я

solo писал(а):Мне бы если бы объяснили по доступней чего куда втыкать на какие пимпочки жимить а то я

Так все же работает. Значит правильно все подключено. А вот задержки - это результат работы драйвера модбас в пользовательском потоке.
Нужен драйвер работающий в потоке реального времени. Тут уже были советы перенести его туда, но как это сделать толком никто не знает. Я, например, не знаю возможно ли это вообще.

Дело не столько в драйвере (порт в компе полностью аппаратный), сколько в ответном компоненте, написанном на Питоне.

Так может общими усилиями можно сотворить "ответный компонент" который будет работать более стабильно . с меня и тестирование

UAVpilot писал(а):Дело не столько в драйвере (порт в компе полностью аппаратный), сколько в ответном компоненте, написанном на Питоне.

Не увидел, где на питоне написано. Все вроде на С.

solo писал(а):Так может общими усилиями можно сотворить "ответный компонент" который будет работать более стабильно . с меня и тестирование

Лично я не хочу тратить время на RTAI. Как будет хотя-бы предрелиз на другом RT, то будет видно...

Impartial писал(а):Не увидел, где на питоне написано. Все вроде на С.

Я внимательно не смотрел - вроде встречались тут какие-то скрипты на питоне...
Ну если ошибаюсь, то значит ситуация чуток лучше.

solo писал(а):Так может общими усилиями можно сотворить "ответный компонент" который будет работать более стабильно . с меня и тестирование

nkp вроде все разложил по полочкам. Лучше не получится.

Impartial писал(а):Нужен драйвер работающий в потоке реального времени. Тут уже были советы перенести его туда, но как это сделать толком никто не знает. Я, например, не знаю возможно ли это вообще.

я уже писал:
можно попробовать исключить юсб, используя Serial1 , на стороне емс - ладдер в реалтайме но со своим более медленым потоком...
(вроде бы предварительно пришли к выводу - что в 1мс не влезем)
а тут - 0.1с - может получиться...

Есть в этом одно НО. Последовательный порт эффективно можно обрабатывать только по прерываниям. Ни один компонент или драйвер, в ЕМС, работать с прерываниями не может. А иначе останутся те же самые проблемы и в реалтайме.
Например скорость модбас 19200. это значит в самом минимуме передача ведется со скоростью 1920 байт/сек.
Вопрос: какую скорость опроса регистра состояния приемника выбрать? Ведь неизвестно когда начнется и закончится прием. Поэтому в драйвере ставятся большие значения таймаутов в надежде, что пакет придет полностью за это время.
А вот чтобы сделать работу по прерываниям нужно лезть в ядро линукса.
Я чем дальше разбираюсь с линуксом, тем больше уважаю микрософт.

Impartial писал(а):Последовательный порт эффективно можно обрабатывать только по прерываниям.

Можно для начала DMA задействовать - формировать сразу всю посылку на передачу и сливать за один раз. С приёмом чуток сложнее, но тоже решабельно.
Во всяком случае для собственно передачи/приёма процессор вообще не понадобится, а нагрузку на шину вообще никто не заметит. А в юзерспейсе останется разбор протокола.

Impartial писал(а):А вот чтобы сделать работу по прерываниям нужно лезть в ядро линукса.

Не надо никуда лезть, всё доступно в userspace.

Impartial писал(а):Я чем дальше разбираюсь с линуксом, тем больше уважаю микрософт.

Поинтересуйся на досуге почему wince на arm появилась почти мгновенно, а настоящую многозадачную ОС только в win8 асилили...

UAVpilot писал(а):Можно для начала DMA задействовать

Можно проще. У нынешних COM-портов есть FIFO минимум по 16 байт на прием и передачу. Вполне достаточно, чтобы целиком поместились небольшие пакеты modbus. Так что, если разрешить FIFO, можно выплевывать пакет целиком и не заботиться о переполнении буферов. То же и с приемом. Можно изредка (в сервоцикле) опрашивать наличие данных. Как появятся - выгребать.
Вопрос только в том, что всё это надо делать. Готовых кубиков вроде бы пока нету.
Можно взять за основу serport и переделать, чтобы использовать его не только как ногодрыгалку, а как полноценный драйвер последовательного порта.

FIFO задействовано по дефолту.

UAVpilot писал(а):Можно для начала DMA задействовать - формировать сразу всю посылку на передачу и сливать за один раз. С приёмом чуток сложнее, но тоже решабельно.

Ком порт в стандартной архитектуре IBM не подключен к ДМА. Так что обмен по ДМА невозможен.

Сергей Саныч писал(а):Можно проще. У нынешних COM-портов есть FIFO минимум по 16 байт на прием и передачу.

Не поможет. Заполнение фифо все равно нужно опрашивать. И какая разница в этом случае каждый байт или фифо полностью.

UAVpilot писал(а):Поинтересуйся на досуге почему wince на arm появилась почти мгновенно, а настоящую многозадачную ОС только в win8 асилили...

Мы находимся на форуме любителей и говорить загадками, по моему , не очень хороший вариант.
Подобные утверждения нужно хоть как то обосновать.

Impartial писал(а): Заполнение фифо все равно нужно опрашивать. И какая разница в этом случае каждый байт или фифо полностью.

Существенная. Имея аппаратный FIFO, можно быстро загнать туда целый пакет и не спеша, раз в сервоцикл или еще реже опрашивать готовность приема. Достаточный размер буферов фифо (больше пакета) гарантирует отсутствие потери данных.

UAVpilot писал(а):FIFO задействовано по дефолту

Системой. Мы же планируем отобрать порт у ОС и работать с ним сами. В serport это как-то сделано, но я пока не вникал, как именно. Потом можно порт перенастроить под свои нужды.

Impartial писал(а):Есть в этом одно НО

как бы там не обстояли дела , но не лучше ли в любом случае исключить юсб??
вот solo выше говорил о помехах,вырубающих модбас...
возможно ,при непосредственной коммутации через компорт проблема снимется...

nkp писал(а):но не лучше ли в любом случае исключить юсб??

По USB всяко полнО неопределенностей, даже при безупречной работе адаптеров. Работать с USB, не используя драйверы ОС - это нереально (практически). COM-порт же - довольно простая железяка.

nkp писал(а):вот solo выше говорил о помехах,вырубающих модбас...

У меня такое тоже было (USB адаптер на базе FT-232). Вылечилось исключением кабелей USB (адаптер втыкается прямо в материнку).
Но у меня через модбас подключен только инвертор, а там быстродействие особое не требуется.