Tandem Readouts?

[Ox1]

Has enyone writ the code for duals yet?

I want ABS AND DIST TO GO side by side.

They say that it can be done - we just need to write it - and it is down deep into the C++ areas. (Whatever that is?)

It's not at the top of my priority list, but I doo have a hole in the top right of my screen for it. I'd like to git that blue sky covered up one day. (Not that we're up and running yet by eny stretch.)

We should be able to git there eventually, but hey - if somone else has been there / done that - well I'd be abliged for the road map.


---------------

Think Snow Eh!
Ox

[Karl_T]

The quick and dirty apparoach: Create a LABEL that has your value. Set Timer.fil to run several times per second and update the LABEL. You'd probably have some flicker and disagreement in the last digit.

The really NEAT and KEWL way. Use visual basic, C, etc. to write a small .exe program. Have it run in a separate window on your screen.

Karl

[Ox1]

Yeah - I want a seperate winder.

Of course the labels could be used for quicker service.

Was just wondering if enyone had done it yet.


-------------

Think Snow Eh!
Ox

[HuFlungDung]

It would be fun to be able to write a GUI, wish I knew how.

One thing I like about the Mitsubishi display is a coordinate display for "Next" moves for all axis. That is the cat's ass. It gives you the incremental distance of the move after the present one, and it isn't changing so fast that it is meaningless. Besides, when single stepping through the program (on a lathe job) you can darn soon decide "hey, I don't want to go that far!"

Knowing that the display updates are rather slow when running Camsoft, I don't know if Distance to go would live up to your expectations. As Karl suggested, it might be possible to rig up a "Next" display in the form of a set of labels that might look like a poor man's digital display. You'd have to write the logic somewhere (in the G01 and G00 logic) to compute the label contents from your gcode.....I'm not sure how much that might bog down the PC when running short segment gcode.

Edit: just thinking about this, I am not sure exactly how you would 'read ahead' one line of gcode in Camsoft, so that you could grab the coordinates and do a difference operation between the current move and the next move.

[Karl_T]

Edit: just thinking about this, I am not sure exactly how you would 'read ahead' one line of gcode in Camsoft, so that you could grab the coordinates and do a difference operation between the current move and the next move.

DISTOGO is a command in the camsoft language. So that part is a piece of cake. I'd do this task with a timer of about 0.1 sec. and a real nice label. That's real slow for the computer, the human would notice a slight disagreement in the .0001 field for fractions of a second - not important most likely. More important, I could get this running in one hour.

Karl

[HuFlungDung]

The regular axis displays on my Camsoft interface update rather slowly, it might be due to running on an older PC, but they seem to update maybe every 1/4 sec or so.

Distance to go might be easy, how about "next"?

[Karl_T]

The regular axis displays on my Camsoft interface update rather slowly, it might be due to running on an older PC, but they seem to update maybe every 1/4 sec or so.

Distance to go might be easy, how about "next"?

I've not seen the slow update problem. I've settled on one PC for all my machines - an HP Compac D530 tower with a P4 2.6 to 3.06Ghz. running XP SP1 stripped for performance. Many HD clones and all parts interchange. Cost about $50 on fleabay. I do still own a couple galil 17x0 cards. To run these I use the same case but install a Soyo P4 ISA motherboard. This MB uses the same processor and memory as the HP.

I can visualize how to do next if you really need it. Create a buffer stack; all Gcodes call buffer macro. The first time you see a Gcode the buffer just records info and exits. The second time it records info and runs the previous Gcode. And so on. This could end up being tricky.

Karl

[HuFlungDung]

Karl,
That is an interesting idea, to run the gcode through a macro first, in order to decipher the next move as an incremental value.

Maybe the Camsoft tech can chime in here, but I'd have to wonder if the way that computer programming works, is it really possible to run a text macro as fast as one could expect proper C+ programming to run, even if the macro were written as perfectly as it could be? How much overhead is there in making Windows rerun that macro 1000 times per second, if you happened to be running short segment 3d code on a mill?

[camsoft]

You can get fast enough response from a C++ routine that would display another readout side by side. This would not use a MACRO. A text macro would not run nearly as fast as a C++ or VB program. We can answer this in two ways. Since a macro would need to be called by another routine, not even a TIMER.FIL file would call a macro 1000 times a second. Although, the code inside a macro, could execute logic on average about 10,000 times a second, so if written as to run in a GOOP LOOP it could execute a text macro very fast, but this would bog down the PC because updating the screen display too fast is a lot of Windows overhead but for readout display purposes on the screen you would only need to run the routine 4-5 times a second or else the numbers would start to blur.

When running very short segments in a 3D file where there are very short line segments to execute we have a feature called FASTMODE that actually suppresses the G code display so splines and 3D files can run at their fastest.

We are glad you asked, because this gives us a chance to talk about how we wrote our own drivers for the Galil card that far surpass the restrictions of how fast native Galil commands can execute. The end result is that we can offer the fastest cutting speeds there is for mold makers. To do this the software drivers have to talk directly to the board. We can process data to the Galil board faster than most machines can cut. So fast that if we did update the screen this would actually slow the cutting down. The G code would fly by so fast you wouldn't be able to catch a glimpse.

On most CBK file interfaces using the default operator interface and G codes for a particular machine. There's a button that toggles between ABSOLUTE & INCREMENTAL displays. The nice thing is that you can add to any of these buttons more commands such as TOGODISP or MACHDISP to flip between readouts.

If you wished you could make separate windows or screens but you'll need to use our CamSoft.DLL (API) using VB or C++. There have been OEM's that private label our software that show Distance to Go, Absolute, Incremental or Relative to Machine or Job Zero.

With our real-time solid modeled simulation or wire frame graphics animation, visually showing the tool cutter move on the screen while cutting it's both quicker & easier to just look at the graphic window to get a sense of were the tool is now, where it's has cut (colored in) or where it is about to move next (graphical gray tool path show as not yet cut)

There is a fill-in-the-blank box under DESIGN OPERATOR INTERFACE on the CNC SETUP window called DISPLAY LINES OF G CODE where you can enter the number of G code lines to display. It will tell you there that a negative value will show how many of the next lines of G code to display.

Tech Support
CamSoft Corp.
support@camsoftcorp.com
PH 951-674-8100
Fax 951-674-3110
www.cnccontrols.com

[Ox1]

There is a fill-in-the-blank box under DESIGN OPERATOR INTERFACE on the CNC SETUP window called DISPLAY LINES OF G CODE where you can enter the number of G code lines to display. It will tell you there that a negative value will show how many of the next lines of G code to display.

As ours is not up and running yet I wuzn't sure, but I ass u me'd that this was the case.

???

AFA the distance to go thing - The only practical use for this is when the feedrate is such that you CAN actually follow it - but as far as I'm concerned - the biggest benefit of this is on initial run through of a new (or edited?) program when you can stop the motion (generally Z) just before it hits the part and dbl check that it has a "Dist To Go" value that looks right.

...And at that purpose - it aint somethin' that I see needing "updated" forty-leven times a second. My brain may be able think on it's own that fast - but I kant consciously harness it that fast - so no point.

Shirley beats burying a C-drill 2" deep in the part!



-------------

Think Snow Eh!
Ox

[HuFlungDung]

Thanks to Camsoft for that answer.

Another question that is relevant to this topic: can one run the Camsoft GUI across two monitors if one has Windows set up that way? I've got a lot of stuff crammed onto my one and only monitor, and I hate to lose sight of all that by going on to a full screen axis display. I recall there are hotkeys to quickly switch around but I've never gotten into the habit of using them. With tandem axis displays, I'd be even more hard pressed for screen space.

[Karl_T]

I've done Camsoft on dual monitors on this computer, my office unit. Just demo mode, but I'm sure it would work on a machine control also.

Karl