Hi Adri,

My first question would concern the CW value you have set on your controller(s). See our command reference (page 71) here for more information:
http://www.galil.com/download/comref/com_2xx0.pdf

Essentially if the second argument of CW is set to 0 (Default), you will see a serial timeout that is indicative of a full serial input buffer (as shown by the TX line being constantly on). Setting the second argument of CW to 1 will avoid the timeout however any additional data you attempt to put into the output buffer will be lost.

You mention that communication with the DMC Terminal does not cause this timeout but your host program occasionally does. Is your host program written on one of the Galil libraries (DMCWIN32 or Galil1/Galil2) or are you using a custom driver (straight serial commands through a bare socket?).

Please try interrogating/changing the CW argument to see if this alleviates the behavior you are seeing so we can investigate further if required. Issuing MG _CW4 from the terminal will return the value of the second CW argument.

Hello MattK, Thank you for considering my issue !

With both the PG laptop or machine computer, we use the DMC Terminal. It is not same version, but they react the same way. We don't have a host program at all !
- In the "recipe" sent to the Controller, the Sub #AUTO has the following command "CW 2,0 ;NO (2,0 = without control (don't display MG))". Each recipe has this command. Each recipe is a .dmc file we send through RS232 only once for a product to be made
- I went to the machine after power ON. On Manual mode MG _CW and MG _CW4 answer respectively 1 and 0. On Automatic mode the answer is 2,0.
getting back to manual mode, the answer is still 2,0
- As the recipe directly affects the CW value, i guess it is useless changing CW value

When the problem exists, even the first connexion after power up fails. How can the input buffer be full in this case ? (no other software would open the serial COM port). Is there other clues ?

Thank you

Hello,

The problem appeared again this morning. The servo axis were unplugged and it seems it gives problem. This is the single Galil system we have in our factory. That's why i am very unconfident with this part.
Now i can connect with RS232 (laptop or machine's computer) or USB (laptop only).
When the Controller was crazy, meaning uncontrolled outputs, generating full speed or oscillating setpoint (X), and TX was fully on. I couldn't connect with DMC Terminal.
I tried to unplug measuring wheel = still crazy, speed setpoint = drives stops. I also played the DIP switch 10 (USB) to try connexion through usb. Nothing good happened.
But when it suddenly went back to something better (Serial TX normal, output and setpoint still anormal). I could connect again, after new power-up. I successfully connect through USB, may be useful for future.
The MG _CW4 and MG _CW commands returned '>'
And the RS retruned this sentence :
>d 000001FE 0000FFFF 00000CC2 00000041 FFFF03DF 4E540000 00000000 0000C001
a 000BF046 000B93DE 00001100 00166928 000BECAA 00002CFB 00002B06 0003FFD2
m 00000000= 10EDC1CC c 2300 _____ p 000B93E8
>
Then MG _RS :
>>OS20-2.0d
>>>d 000001FE 0000FFFF FFFFFFFE 00000041 000003DF
Only then, i decided to Master Reset the controller and get it to normal operation mode

So what means those strange answers from RS and MG _ RS ????
Thanks in advance for any clues !

Hello,
Yesterday 6am, i changed the DMC2020 with a DMC2120 (or 2220) we had in spare. Same dimensions, only USB becomes Ethernet but we don't care. After checking the jumpers and DIP switches, it was in fact plug&play for this application.
Up to now the controller reacts good : when sending incorrect commands such as "toto" or "test" it answer invalid command or wrong parameter.
I am also doing some maintenance on critical devices (Y axis measuring wheel encoder/X axis encoder's cable). This machine lacks of maintenance and is in poor state.
Also, a deep mechanical revision had been done because so much backlashes and wrong clamping of some parts.

It seems the controller DMC2020 is defective as we were not able to produce more than 2hours without problem, even after the mechanical checking.

I contact the French retailor in order to know what to do between send to diagnose or buy a new DMC. Unfortunately they don't know handle this range of prior generation controller.

Thanks for support
Adrien

Hello Adrien,

We can continue to correspond over email regarding the behavior you are observing.

I give this post in case some other people get a similar problem :
I made a firmware update of the disturbed DMC2020, thinking it could be software problem.
Following the Firmware update, it was working good the same day. Asking "TOTO" answers "?1 Unrecognized Command" as expected, and when asking "TE S" it answers "?28 S operand not valid". Before the update it answered "?5 Input Buffer Full" to all invalid command or argument.
But after 1 week without power supply, i tried again : I cannot connect to it. I do it at my desktop and i assume it's free from buzz
More than scrap in the communication link (i don't have oscilloscope to check it on the machine), i think the problem is inside the DMC.
Now is time to consider send it to repair or get a new one.
Thanks for tips you gave me in order to get closer to the problem
Adrien