В последнее время часто задавали вопросы по подключению моторов в поломочных машинах Karcher BD 43/35C или аналогичных.
Основная проблема возникает с блоком запуска двигателя (Electronic start switch), «родные» попадались с маркировкой 1610ECS или китайские типа RECS-205/220/240 (на разный ток). «Родной» блок построен на базе pic12f683 и двух реле (для рабочей и пусковой обмоток). Соответствие контактов следующее:
Маркировка
Цвет провода
Обозначение
Примечание
X18
коричневый
Lin
фаза
X19
желтый
START
пусковая обмотка
X21
красный
COIL
рабочая обмотка
X22
черный
N
нейтраль
Китайский блок RECS-205, RECS-220, RECS-240 выполнен на базе Attiny-44A и тиристора серии BTA… оответствие контактов следующее:
Маркировка
Цвет провода
Обозначение
Примечание
белый
Lin
фаза
синий
START
пусковая обмотка
красный
COIL
рабочая обмотка
черный
N
нейтраль
Прошивки «залочены» так что ремонт сводится только лишь к замене силовой части, хотя в этом не всегда заинтересован клиент, так как возможно подключение без блока запуска.
В ремонте инвертор TBF 3000W 12V (на плате HF2000-PB-A3) — из разряда «жуткая китайская поделка». Транзисторы на выходе (JCS18N50) в к.з., заменил из доступных аналогов, входные предохранители отсутствуют, на плате управления HF200-12-220 rev.1.03 — R28 (обрыв), R11 — (потеря сопротивления). После замены — включился.
Программные продукты Фирмы «1С» в большинстве случаев защищены от копирования с помощью аппаратных LPT или USB ключей защиты типа HASP от фирмы Aladdin. Система лицензирования программ линейки 1С:Предприятие 8 дает пользователям более гибкие возможности масштабирования при увеличении количества пользователей, наращивании вычислительных мощностей информационных систем, росте компании и т.д., но при этом у клиента может оказаться сразу несколько ключей от различных лицензий и версий программ 1С, внешне очень похожих, что может вызвать определенные затруднения.
Маркировка ключей
Маркировка USB-ключа защиты
Маркировка LPT-ключа защиты
Символы, характеризующие вид ключа, обведены на рисунках в рамки. Остальные символы на ключе для пользователей программ особого значения не имеют.
1С:Предприятие 8
Внешний вид
Наименование программного продукта
Маркировка
Однопользовательские версии основных поставок и клиентских ключей
HASP HL Basic не имеет внутренней памяти и уникального идентификатора.
1C:Бухгалтерия 8 ПРОФ 1С:Бухгалтерия 8 ПРОФ. Поставка для розничного распространения 1С:Бухгалтерия 8 КОРП 1С:Бухгалтерия бюджетного учреждения 8 1С:Бухгалтерия автономного учреждения 8 ПРОФ 1С:Бухгалтерия автономного учреждения 8 КОРП 1С:Управление торговлей 8 1С:Зарплата и Управление Персоналом 8 1С:Зарплата и кадры бюджетного учреждения 8 1С:Управление небольшой фирмой 8 1С:Комплексная автоматизация 8 1С:Предприятие 8. Управление производственным предприятием 1С:Документооборот 8 1С:Предприятие 8. Клиентская лицензия на 1 рабочее место
H4 M1 ORGL8
Сетевые версии основных поставок и многопользовательские ключи
USB HASP HL Net имеет уникальный идентификатор и внутреннюю память, в которой записано количество лицензий
1С:Бухгалтерия 8. Комплект на 5 пользователей 1С:Бухгалтерия 8 ПРОФ на 5 пользователей. Поставка для розничного распространения 1С:Предприятие 8. Комплект прикладных решений на 5 пользователей
H4 NET5 ORGL8
1С:Предприятие 8. Клиентская лицензия на 5 рабочих мест
H4 NET5 ORGL8
1С:Предприятие 8. Клиентская лицензия на 10 рабочих мест
H4 NET10 ORGL8
1С:Предприятие 8. Клиентская лицензия на 20 рабочих мест
H4 NET20 ORGL8
1С:Предприятие 8. Клиентская лицензия на 50 рабочих мест
H4 NET50 ORGL8
1С:Предприятие 8. Клиентская лицензия на 100 рабочих мест
H4 NET100 ORGL8
1С:Предприятие 8. Клиентская лицензия на 300 рабочих мест
NET250+ ORG8A
1С:Предприятие 8. Клиентская лицензия на 500 рабочих мест
NET250+ ORG8B
Ключи на сервер 1С:Предприятие 8.*
USB HASP HL Pro имеет внутреннюю память (фактически не используется) и уникальный идентификатор
1С:Предприятие 8.* Лицензия на сервер (х32)
H4 M1 ENSR8
USB HASP HL Max имеет внутреннюю память (фактически не используется) и уникальный идентификатор
1С:Предприятие 8.2. Лицензия на сервер (x86-64)
Max EN8SA
Комплекты
USB HASP HL Net USB HASP HL Pro
1С:Предприятие 8. Управление производственным предприятием для 10 пользователей + клиент-сервер В комплект поставки входит два ключа: Многопользовательский на 10 рабочих мест и на сервер 1С:Предприятия 8.* (х32)
H4 NET10 ORGL8 H4 M1 ENSR8
1С:Комплексная автоматизация 8 для 10 пользователей + клиент-сервер В комплект поставки входит два ключа: Многопользовательский на 10 рабочих мест и на сервер 1С:Предприятия 8.* (х32)
H4 NET10 ORGL8 H4 M1 ENSR8
1С:Предприятие 8. Комплект для обучения в высших и средних учебных заведениях. В комплект поставки входит два ключа: Многопользовательский на 20 рабочих мест и на сервер 1С:Предприятия 8.* (х32)
H4 NET20 ORGL8 H4 M1 ENSR8
Размер USB-ключей может отличаться от размера ключей изображенных на рисунках. Программные продукты системы 1С:Предприятие выпускавшиеся до 2009 г. комплектовались USB-ключами в более длинном форм-факторе — 52 мм. Цветовая схема и маркировка ключей осталась без изменений.
Внимание есть некоторые ограничения на установку ключей: На одном компьютере не будут работать несколько USB-ключей одной серии. Будет работать только один из установленных ключей. Т.е. ключи ORGL8 (как однопользовательские, так и сетевые) вместе работать не будут, но если есть ключ ORGL8 и ORGL8А и ORGL8В, то вместе они вполне уживутся на одной машине. Кроме того, пользовательские ключи могут быть доступны по сети (если запущен HASP License Manager). Таким образом максимальное количество лицензий, которое может обслуживаться одним компьютером равно 900: максимум 100 лицензий в ключе ORGL8, 300 лицензий в ключе ORGL8A и 500 лицензий в ключе ORGL8B. Так же на один компьютер можно установить USB-ключ пользовательских лицензий и ключ Сервера 1С.
Лицензии ищутся в следующем порядке: · в ключе ORGL8, · в ключе ORGL8A, · в ключе ORGL8B.
Серверные ключи устанавливаются только на тот компьютер, на котором установлен сервер 1С:Предприятия. По сети они работать не будут.
Серверные 64-битные ключи также можно использовать и 32-битных системах.
Для того, что бы узнать, какие лицензии заняты/свободны в текущий момент, вам понадобится приложение Aladdin Monitor.
Пришла в ремонт плата после аварии с приходом на вход питания 380В (вместо штатных 220В). Кто-то «криво» перепаял конденсатором 680,0х450В. Горит предохранитель. Пробит импульсный блок питания LH10-20B.
Для личного использования. Информация, взятая из сети сопровождается ссылкой на источник
Function code
The function code (FC) in the telegram header identifies the telegram type, such as Request telegram (Request or Send/Request) and Acknowledgement or Response telegram (Acknowledgement frame, Response frame). In addition the function code contains the actual transmission function and control information that prevent loss and duplication of messages, or the station type with FDL status.
7
6
5
4
3
2
1
0
FC: Function Code Request
1
Request Telegramm
X
FCV = Alternating bit switched on
X
href=»http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit»>FCB = Alternating bit (from frame count)
Frame Count Bit The frame count bit FCB (b5) prevents message duplication by the acknowledging or responding station(responder) and any loss by the calling station (initiator). Excluded from this are requests without acknowledgement (SDN) and FDL Status, Ident and LSAP Status requests.
For the security sequence, the initiator must carry an FCB for each responder. When a Request telegram (Request or Send/Request) is sent to a responder for the first time, or if it is re-sent to a responder currently marked as non-operational, the FCB must be set as defined in the responder. The initiator achieves this in a Request telegram with FCV=0 and FCB=1. The responder must assess a telegram of this kind as the first message cycle and store the FCB=1 together with the initiator’s address (SA) (see following table). This message cycle will not be repeated by the initiator. In subsequent Request telegrams to the same responder, the initiator must set FCV=1 and change the FCB with each new Request telegram. Any responder that receives a Request telegram addressed to it with FCV=1 must evaluate the FCB. If the FCB has changed when compared with the last Request telegram from the same initiator (same SA), this is valid confirmation that the preceding message cycle was concluded properly. If the Request telegram originates from a different initiator (different SA), evaluation of the FCB is no longer necessary. In both cases, the responder must save the FCB with the source SA until receipt of a new telegram addressed to it. In the case of a lost or impaired acknowledgement or response telegram, the FCB must not be changed by the initiator in the request retry: this will indicate that the previous message cycle was faulty. If the responder receives a Request telegram with FCV=1 and the same FCB as the last Request telegram from the same initiator (same SA), this will indicate a request retry. The responder must in turn retransmit the acknowledgement or response telegram held in readiness. Until the above-mentioned confirmation or receipt of a telegram with a different address (SA or DA) that is not acknowledged (Send Data with No Acknowledge, SDN) the responder must hold the last acknowledgement or response telegram in readiness for any possible request retry. In the case of Request telegrams that are not acknowledged and with Request FDL Status, Ident, and LSAP Status, FCV=0 and FCB=0; evaluation by the responder is no longer necessary.
b5
b4
Bit position
FCB
FCV
Condition
Meaning
Action
0
0
DA = TS/127
Request without acknowledgement Request FDL Status/ Ident/ LSAP Status
Delete last acknowledgement
0/1
0/1
DA # TS
Request to another responder
Delete last acknowledgement / response
1
0
DA = TS
First request
FCBM := 1 SAM := SA Delete last acknowledgement / response
0/1
1
DA = TS SA = SAM FCB # FCBM
New Request
Delete last acknowledgement / response FCBM := FCB Hold acknowledgement / response in readiness for retry
0/1
1
DA = TS SA = SAM FCB = FCBM
Retry Request
FCBM := FCB Repeat acknowledgement / response and continue to hold in readiness
0/1
1
DA = TS SA # SAM
New initiator
FCBM := FCB SAM := SA Hold acknowledgement / response in readiness for retry
The two equivalent length bytes in the telegram header of the variable format contain the number of information bytes in the body of the telegram. These include: DA, SA, FC and the PDU. The value ranges from 4 to 249, so that no more than 246 bytes can be transferred to the PDU of a telegram. No value <4 is allowed, because a telegram must comprise at least one DA, SA ,FC and a data byte. The longest telegram therefore comprises 255 bytes overall.
The FCS (Frame Check Sequence) checksum required in the telegram for Hamming distance 4 is always located directly in front of the end delimiter (ED) and has the following configuration:
7
6
5
4
3
2
1
0
0 to 255
Checksum
For the without-data format (SD1) the checksum must be formed by the arithmetical sum of DA, SA, and FC without start delimiter (SD) or end delimiter (ED) and disregarding sums carried over. For the fixed length format with data (SD3) and the variable length format (SD2) the checksum must also include the payload (PDU). Example of bytes added together in the FCS:
In the PROFIBUS DP-V2 version clocks in a PROFIBUS network can also be synchronized. For this purpose, a station is defined as the time master which then distributes the time within its network. This time master must be a master and is designated as a class 3 master.
Clock synchronization
The time master reads its current time and starts an internal timer. As soon as the time event (TE) telegram (see FC: Function Code Request) is sent with the read time, this internal time is stopped. In a subsequent counter value (CV) telegram, the time difference between the read time and the sent time is transmitted.
On receipt of the TE telegram, the receiving station also starts its own internal timer. The value of this internal timer plus the current value from the TE telegram and the correction value from the counter value (CV) telegram give the time to be set.
Sequence of telegrams for clock synchronization
This clock synchronization service must always require the support of hardware to start and stop the timers. Not all modules (ASIC) available on the market can support this service.
The two address bytes in the telegram header of telegrams (Request, Confirmation and Response telegrams) contain the station’s destination address (DA) and source address (SA).
7
6
5
4
3
2
1
0
DA: Destination address
0 — 127 (0x7F)
Destination address
0 1
no DSAP (SAP = NIL) DSAP present
7
6
5
4
3
2
1
0
SA : Source address
0 – 126 (0x7E)
Source address
0 1
no SSAP (SAP = NIL) SSAP present
Address 127 is reserved as a global address for broadcast or multicast messages (telegrams to all bus users or user groups selected via service access point; only allowed with Send Data with No Acknowledge, SDN). The address byte of the Request telegram should be reflected in the Response telegram in reverse, i.e. the SA byte of the Response telegram contains the destination station address and the DA byte the source station address of the Request. For formats with a PDU, the address extension serves to identify a destination and/or source address extension in the form of a Service Access Point (SAP) that immediately follows the FC byte in the PDU. The address extensions of a Request telegram must be reflected in the Response telegram in reverse. If the address extension bit has not been set, it is the special SAP = NIL. This Service Access Point has the advantage that its telegram is 2 bytes shorter and is therefore used for cyclic data exchange.
не имеет внутренней
имеет уникальный
имеет внутреннюю
