[Rekd]

Should be able to copy the executable over. Worked on my other machine. What are you running?

Either way, I'll re-compile the setup tomorrow, and get you updated. May be something to do with the progress bar, although that control was already loaded, just not being used. Besides, the progress bar isn't an array, which now makes me wonder.. the only array with 12 items is the com ports.. hrm. This could get interesting. Please lemme know what OS you've got on the errored machine. Thanks.

'Rekd

[JamesBond]

Reked,
I removed all scomm entries in the registry, deleted the installed directory, reinstalled the program and copied the latest version, and all is working.

I am using scomm only with windows XP machines.
Thanks, -JB

[cadcam]

Reked this James Bond is not my brother inlaw from the other board..
Is that waht you were thinking was Scott Bond from emastercam?

[Rekd]

James. Glad to hear it. Please lemme know if you find anything wierd. I'm really liking the recieve module and the progress bar. And yes, the fader only works in XP and (presumably) W2k.

Jay, I had confused them, saw the bond and spliced the two together in my mind. Kind of like I almost did with you and cadman at first. Almost replied to something he wrote as if I knew him for years.

'Rekd

[Rekd]

More updates..

It's compact

The echo window displays 1 line at a time.

Controls were moved around a bit to make it more compact. (Yay! I can justify the fader now!! )

Keep a copy of the .exe you're using now until you've proofed it out.

I've tested it all day and it seems good.


Here's the executable.. Screenies on next 2 posts.

'Rekd

[Rekd]

screenie

[Rekd]

..shown

[Rekd]

It will test for the " % " now, and add it to beginning and end if it's not in the file. There is no switch for it now, it just does it automatically. That may come later, but I'm not aware of any machines that don't require that.

If anyone reading this has seen a machine that doesn't require the " % " at the beginning and end of an RS232 or floppy transfer, please lemme know. :cheers:

'Rekd

[tahlinc]

Take a look at http://www.softsqad.com/CS-Lite.htm
Its free and I like it.

[webtwingo]

Hey Everyone,
Anyone looking for a simple, but highly effective way of getting your NC data organized and transfered to / from the machine.

Take a look @ "CAMback easy" on http://www.evo-solutions.com

* It's a universal transfer tool supporting all possible controls!

* It helps you organize your data in tree views according to criteria like machine type / type of file / .....

* It runs on all current Windows systems: Win95 / Win98 / WinME / Win2000 / WinXP

* It's the easiest NC transfer tool I've ever seen!!!

Take a look @ it on: http://www.evo-solutions.com
This is software developed according to highest German quality standards - please drop us a note if you're interested in an international version!

CAMback

[coldplugs]

Originally posted by Rekd

If anyone reading this has seen a machine that doesn't require the " % " at the beginning and end of an RS232 or floppy transfer, please lemme know. :cheers:

'Rekd

It seems to me that there were quite a few machines over the years that don't require the %. BostoMatics with SPC-II controls (80's vintage) and EMCO controls didn't need them. I'm sure there are others.

You're probably right though, that most machines today use a %.

[Rekd]

Originally posted by coldplugs
It seems to me that there were quite a few machines over the years that don't require the %. BostoMatics with SPC-II controls (80's vintage) and EMCO controls didn't need them. I'm sure there are others.

You're probably right though, that most machines today use a %.

Do you know how these machines would react if the recieved the %?

'Rekd

[coldplugs]

Originally posted by Rekd
Do you know how these machines would react if the recieved the %?

'Rekd

Sorry - no, I don't. I suspect they'd ignore them on the download but might choke when the program is run if the character got transferred to memory.

I've written an "in-house" DNC system and 2 simple commercial systems and made start and end characters an option without really thinking about it. My experience is that, if you don't do things like this, your first user will need it. If you do it, your "support line" will be that much quieter.

[Rekd]

I've made a simple comm program as well, and recently added support to add the % if needed.

Question; how much different is a DNC program than a typical comm program? (I'm using VB6)

I've DNC'd with my comm program, but I don't think it has all the error checking and RTS CTS and all that. I've been considering a full fledged DNC but am not sure how to go about it. Any suggestions?

Thanks.

'Rekd

[coldplugs]

Originally posted by Rekd
...
Question; how much different is a DNC program than a typical comm program? (I'm using VB6)

I've DNC'd with my comm program, but I don't think it has all the error checking and RTS CTS and all that. I've been considering a full fledged DNC but am not sure how to go about it. Any suggestions?

Thanks.

'Rekd

For simply transferring a program to a controller, there's not much different from a typical comm program. But for drip feeding (usually with X-on/X-off), I've found that things seem to work well only if you send a single (CNC) block at a time, or at least make sure that your Windows buffer ends with a complete, and not a partial, CNC block.

Performance is also important for drip-feeding - the DNC program needs to react quickly when the CNC requests data. I try to do any file formatting (e.g. remove sequence numbers) ahead of time so that no string manipulation is needed during the transfer iteslf.

Whether drip-feeding or not, you'll probably hit CNC issues relating to end-of-lines characters. Some want CR/LF, some want other combinations. I handle this reformatting ahead of time as mentioned in the previous paragraph.

One other thing comes to mind - some CNC controls are a little slow to react when you send them data and they fill their buffer. One way to handle this is to allow a short delay between blocks.

I did one system with VB5 that worked pretty well although performance was never great.

For file transfers, though, VB should work fine. You can improve things by getting one of the add-on comm controls. Their manuals relating to comm issues are usually worth the price of the control.

This stuff's fun to write, isn't it. It can be frustrating but you get a sense of accomplishment when you get 2 machines talking.

[Rekd]

Originally posted by coldplugs
For simply transferring a program to a controller, there's not much different from a typical comm program. But for drip feeding (usually with X-on/X-off), I've found that things seem to work well only if you send a single (CNC) block at a time, or at least make sure that your Windows buffer ends with a complete, and not a partial, CNC block.

Performance is also important for drip-feeding - the DNC program needs to react quickly when the CNC requests data. I try to do any file formatting (e.g. remove sequence numbers) ahead of time so that no string manipulation is needed during the transfer iteslf.

Whether drip-feeding or not, you'll probably hit CNC issues relating to end-of-lines characters. Some want CR/LF, some want other combinations. I handle this reformatting ahead of time as mentioned in the previous paragraph.

One other thing comes to mind - some CNC controls are a little slow to react when you send them data and they fill their buffer. One way to handle this is to allow a short delay between blocks.

I did one system with VB5 that worked pretty well although performance was never great.

For file transfers, though, VB should work fine. You can improve things by getting one of the add-on comm controls. Their manuals relating to comm issues are usually worth the price of the control.

This stuff's fun to write, isn't it. It can be frustrating but you get a sense of accomplishment when you get 2 machines talking.

Thanks for your reply.

Setting the buffer size to the block size seems a bit tricky. Considering the blocks will be different size, the buffer size will have to be dynamic. I can see that this could pose potential problems because you'd have to set the buffer size each time you hit a CR/LF. Or am I out in left field again?

My app uses the standard MSComm control. I've recently considered winsock or a third party control for flexibility/reliability, but being a novice am a bit shy.

Thanks again.

'Rekd

[coldplugs]

Originally posted by Rekd
Thanks for your reply.

Setting the buffer size to the block size seems a bit tricky.
<...snipped...>

My app uses the standard MSComm control. I've recently considered winsock or a third party control for flexibility/reliability, but being a novice am a bit shy.

Thanks again.

'Rekd

I wasn't suggesting that you change the buffer size. What I actually do is load the buffer with a single block, or some number of blocks, send it, and wait for the count of characters waiting to be sent to hit zero. The important thing is to make sure that the last block in the buffer is complete, and not a partial block.

Re third party controls, I once used "PDQCOMM" by Crescent Software, which was very compatible with the MS control. I don't think it's available these days but something like it must be.

Anyway, if your code's working I wouldn't worry about it...

[Rekd]

James,

Still using SComm? How's it working? I've made lots of upgrades. I'll post some screenies.

'Rekd

[JamesBond]

It has been working great!
I use it daily and have had no problems.
It is one utility that makes my downloading so easy I don't think about it anymore, it just works.

What improvements have you made lately?
Thanks, James

[Rekd]

Glad it's working out for you.

I've added more error checking for the code as well as the actual transfers.

I've added some options for the way the polling works. (You may not use this, but I have 5 different comm ports on my computer, and can select which port to send to when sending the file name to SComm)

It will check for the % at the beginning/end of the file and send it if it's not there. (I think you may already have this option, not sure cuz I don't remember what version you're using.)

I fixed some problems with the Reset button being pressed manually, as well as when it's set in the options to automatically reset after the transfer.

I made a little cheesy text based help file to explain what the options do.

I've added a logging feature, and am working on allowing user to limit the log's file size.

I added Explorer Shell Menu capabilities, so you can right click on a file in Explorer, and select SComm from the menu. This is not set up by SComm at this time, as there are too many different ways for people to set up their file extensions. But I can walk you thru setting it up yourself. It's really easy. This will (hopefully) be an automatic process in the near future.

The interface hasn't changed much, but I did add tabs to the options, as it was getting rather crowded having everything on one page.

Have a look at the screenies.

'Rekd