Philips CSM66.xls to create BRD & FDR files easier

Subscribe to Thread

Hi to All, I have bought my CSM66 ~3 years ago. It has a ... - Jun 21, 2007 by andras

I did things using a language I am more familiar with, and i... - Jun 21, 2007 by jmelson

>Is anyone else using XON/XOFF handshaking, or is it best to... - Jun 22, 2007 by sarason

&F(27).NO4=0 NO4 is for the prep head, which you probably d... - Jun 22, 2007 by jmelson

andras

#50779

Philips CSM66.xls to create BRD & FDR files easier | 21 June, 2007

Hi to All,

I have bought my CSM66 ~3 years ago. It has a not too user friendly interface... :-( But fortunately it has a great possibility to upload files via RS232. So I have created a simple excel sheet to build those tricky BRD & FDR files. Here it is: http://andras.4shared.com/

Regards: andras

reply »

jmelson

#50782

Philips CSM66.xls to create BRD & FDR files easier | 21 June, 2007

I did things using a language I am more familiar with, and it allows me to set up a list of components, feeder locations, pick-up orientations, proper head to use, etc.

My problem is I haven't gotten fully reliable communications when downloading the files to the CSM. (Mine is a CSM84, PA1306/40) but I suspect they are all very similar. I have it set up for XON/XOFF protocol, and am using a linux system to download from. I don't entirely trust the linux comm program in regard to handling the XON/XOFF, so it could be entirely on the linux/comm program end. Anyway, if I set everything up for XON/XOFF, what appears to happen is the CSM84 reads about 1 K of data and then sends an XOFF, the comm program stops, and never receives an XON to continue the transmission. I haven't put a comm analyzer on it yet to see what exactly is going on.

My horrible workaround is to slow down the transmission to 10 chars/sec and ignore XON/XOFF at the linux PC. This works, but I always worry I'll miss a character in the middle of the file.

Is anyone else using XON/XOFF handshaking, or is it best to use CTS/RTS hardware handshaking? If you are using XON/XOFF, what parity settings are you using? (Not unheard of for the XON/XOFF chars to not obey the parity settings for data chars.)

Thanks,

Jon

reply »

sarason

#50786

Philips CSM66.xls to create BRD & FDR files easier | 22 June, 2007

>Is anyone else using XON/XOFF handshaking, or is it best to >use CTS/RTS hardware handshaking? If you are using >XON/XOFF, what parity settings are you using? (Not unheard >of for the XON/XOFF chars to not obey the parity settings >for data chars.)

I had problems with downloading files to my Yamaha machine, using hardware handshaking. So I tried slowing the speed adding delay on character transmission, making up a new download cable (turns out I left a wire out of the new cable, connected both SG and FG together). But then I worked out that the BRD and FDR format are incredibly finicky on what they will receive as valid file formats. I initially used the @ char instead of the % char in the the BRD and this made the file unreadable. Also the PCBNAME line name had to be 8 Uppercase characters, no spaces. All COMMENT names have to be less than 8 chars. All spaces have to be space ,no tabs allowed. Also the Order and the no of digits in the BRD mount points were not as in the documentation that I had. Ex. M133 = 44.75 56.85 270.00 100058 the 1 in 100058 is the head no. the 058 is the feeder no.(yes it needs the extra 0 to be correctly justified.) the last 0 in 100 is the skip command. the fist 0 in 100 is meant to be the point fiducial ( I am still trying to get this to work today)

Now my question for you. what do these lines: &F(27).NO4=0 &F(27).DSPF=1 mean in the FDR file.

regards Andrew

reply »

jmelson

#50788

Philips CSM66.xls to create BRD & FDR files easier | 22 June, 2007

&F(27).NO4=0 NO4 is for the prep head, which you probably don't have. So, it is zero to mean don't use the prep head. &F(27).DSPF=1 This is the "display flag", it apparently means this component slot in the file contains valid data for a real component. A zero would make it not show up on the screen (I think).

Thanks for the rest of the info. I have the file format down OK, as it works when I send it reall slow. So, it is just a handshaking problem.

Jon

reply »