keyboard jog

[HuFlungDung]

Hi Camsoft (or other interested retrofitters, too)

You probably are well aware of my gripes already with keyboard jogging

The gist of my gripe is this: I cannot control the amount of the jog amount, because there seems to be no logic to specify it. So, I try various holding of the key combos (which is not handy, nor as safe as it could be, I might add) for various time intervals to try to jog up by a wee bit. This is next to impossible, no let me say it is simply impossible to have any real degree of control.

Because of this, I have made no attempt to use automatic tool length offset logic, which is easily obtainable, but only perhaps useful for those who have the precision of a manual pulse handwheel.

So perhaps I have overlooked some methods that might be within my grasp in the jog.fil logic, although I highly doubt that I can get the response that I want from that, in its current state.

Now computer games have taught me that Windows can respond very well to keyboard event inputs, so how can we capture a bit of that and use it on our cnc's?

I can elaborate more (and again) how I would like to see keyboard jogging implemented, if you like.

Thanks

Similar Threads:

• What keyboard are you using?
• 97 Arrow 500 add a keyboard?
• Problem- Milltronics Keyboard Error or No Keyboard Present
• PC keyboard for Ultimaxx ssm ???
• Problem- keyboard,,

[agentsmith]

HuFlungDung.

Part of the keyboard jog key combination functions is the incremental jog. Have you tried this key combination. Use the Key combo Alt-Arrow. Alt brings up text box in the JOG control on the Main CNC Window where you can type in a distance.

Hope this helps.

[HuFlungDung]

Thanks for the alert, Agentsmith. Its been so long since I used that, that I confess it had slipped my mind

But, the reason why I "fogot" about it, is all the complexity of keyboard jogging in general. It's like playing a game of Twister with one hand, while you're trying to not chip your tool insert, because that is where you'd be looking

Although the dual key combo Alt+ key or CTRL+key or SHIFT+ key sounds like a great system for jog control, it is not great to use in real life. It is entirely too complex, IMO. This drives users to unnecessarily invest in an expensive handwheel for jogging.

For one thing, the system response to a quick jab of the keys is all too often, no response at all. This is no good. I want to be able to tap a single key and watch the machine move, just as fast as I can tap the key.

IMO, the necessity of choosing X, Y or Z axis to jog in is another strike against user friendliness. The Bandit controller had a keypad the same as your numberpad on your keyboard. When in jog mode, "4" and "6" were X axis, "8" and "2" were Y axis and "5" and "0" were Z axis. The divide key was used for a Hi or Lo jog toggle state.
This is extremely handy to get around with. It becomes second nature, and you don't have to even think about getting your hand in some kind of a contortion to do a jog move, only to find out that you were on the wrong axis, etc.

Its nuts, as far as I am concerned, to abandon the Bandit keyboard jog, for those who like keyboard jogging. If you (in a plural sense) have never used one, you would not know, perhaps, how handy it is.

I like the concept of the variable jog length in Camsoft Alt+key, in order to be able to get into jog increments of less than .001", but that would be about it.

Hi jog mode, in Bandit, is simply an initial movement of .1" in whatever axis direction is being pressed. If you hold the key down for longer than 1/2 second, then smooth continuous motion begins in that axis at high jog rate (or Rapid, whatever you like).

Lo jog behaves the same way, but the initial increment is .001" and then a sustained press gives way to smooth Lo jog movement in that axis.

It is beautiful in its simplicity. I'd either like to be able to write my own jog logic to do this from the keyboard in Camsoft, or they can integrate it directly (fat chance ) into the executable. But, currently, there is no joy for me in jogging at all.

Maybe I should just write another Galil program for jogging. I could, but I'd have no way of getting keyboard input into the card anyways, without spending hundreds of dollars on unnecessay I/O and pushbuttons to do exactly the same thing as the keyboard should be doing.

[HillBilly]

Hu,

I will agree. I can tap tap tap my single shift key on my MaxNC software (cheap stuff) and bump the least increment everytime. I don't know if it is set up this way or just responds this good.

Darek

[agentsmith]

Guys.

The basic jog function on the CNC Main screen is really a poor mans jog function. A PC Keyboard is not really meant for this function. In the controls you mention, sure their keyboards have better response but the control is specifically programmed for this function and the keyboard may even have been manufactured specifially for this control. They program for the same keyboard. If you want a keyboard specifically manufactured to your specification, you won't be spending the $7 dollars for the cheap-e windows keypoards you can get with your pc. PC Keyboards can come in different flavors. If camsoft were to customize for one particular keyboard that means other keyboards might not work. You would have to configure for every different type of keyboard out there. Do you want another configuration choice on the list of stuff you need to do? You would be locked into having to use a particual keyboard and that would hinder one of the goals of the software architecture which is to try to be open and to work with a multitude of devices to give you choice. For a basic function, the basic jog feature works great. I works out of the box and I don't have to worry about what keybaord I'm using.

But...this doesn't mean you can't program function into the software. Why not program the function keys for some custom jogging functions. Or better yet, program some pushbuttons on a panel. This would give the best result. You know, you could probably spend some money and purchase a Keybaord or keyboard which could interface with digital IO or talk through RS-232 that you could program to. Or what about using the Camsoft API to control your keyboard in your own application the way you want to. There lots of choices and techology out there.

[Al_The_Man]

One feature I really like on the Acromill for DOS (our shop machine) is the keyboard jog buttons. The Four arrows up/dn = Y axis. left/right = X axis and Pageup/pagedn= Z. It also displayed on the screen in case you had touch screen.
Also you could set them to incr jog from .1 down to .0001.
Al

[camsoft]

The messages are coming fast on this subject. In order not repeat what was said. We can summarize by saying. We ask the user to hold down two keys at the same time for safety reasons.

We just tried taping on the arrow keys while hold the shift key down and it's still pretty fast response if you set the ACELL and DECEL rates up high in the JOG.FIL file. The point is however that the rapid jog or slow jog keys are for appox positioning. The system does support an incremental jog with a user define distance using the ALT key + arrow key. This is what most people use with an edge finder or dial indicator.

Thank you, agentsmith. Your key board theories are correct and yes, you're also correct the standard key board feature is a poor mans jog function.

There are so many other choices with CamSoft. (1) $25 Joy stick, (2) Real physical buttons using digital I/O, (3) a touch screen jog and (4) of course a handwheel.

Tech Support
CamSoft Corp.
(909) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

[HuFlungDung]

I beg to disagree with you guys, but from a state of ignorance about keyboards, I'll admit. A keyboard can typically be set to repeat at up to 30 chars per second, which BTW, exceeds the speed at which I can type or tap. This seems to be nowhere near the response I get in jog mode.

BTW, the Bandit is about 25 years ancient now, so I really doubt that their keyboard polling rate was any better than what a modern PC can muster.

I can easily outjog anyone running a Camsoft handwheel in Bandit's general purpose 3 axis jog. The reason you guys look down your nose at keyboard jog is the same reason as I do: the keyboard jogging sucks so bad in the Camsoft gui, that it might as well not even be in there. I'd gladly trade enhanced functionality in jogging for mid program start with the mouse, which I cannot see why the effort was made to create such a function. I just would never trust it. But that is another topic.

Do you even stop and consider what I've said about the Bandit jog? Safety is not the issue, in fact, thanks to the two-key combo in Camsoft's jog, I've made blunders that would never happen on Bandit. So, I quit using it, if at all possible.

For another thing, there is some kind of a flicker across the CRT screen (version14.7), whenever the jog buttons are pressed and released, as though there is some substantial calculations or logic being run in the background, which must be loaded and unloaded every time a key is pressed. I wonder what could be the cause of this? Does it have anything to do with the jog file being read when both entering and leaving jog mode?

But, I will try modifying the accel-decel rates in the jog file because I had not thought about that. That still does not address my main gripes about the whole keyboard jogging issue. I don't like it, and I am willing to figure out how to change it, but it needs to be part of the configurable gui. Like I said, why should I have to spend $1500 for jog function by using third party hardware? It doesn't make sense to me.

[agentsmith]

I've used the basic keyboard jog feature and have never seen the screen flicker like you describe. I use clone computers with bare minimum systems, that is the OS doesn't run alot of other junk in the background. The flicker sounds like some windows problem or video card issue. What OS do you see this with? What type of computer? How much ram? What video card and vram? Try dowloading the latest drivers for your video card.

[camsoft]

Hi Hu,

Theres gotta be something more to this. Something else is wrong. The keyboard is detecting a press/release faster than humanely noticeable right now. Motion on the other hand won't begining until several factors are met.

The system has to read stable position feedbasck, No drifting or oscillation.
ACCEL rate has to be high enough to ramp up to a speed that is noticeable. This values is entered in counts per second of time. DECEL too has to be high to stop the motion, so it doesn't glide. Motor size to deliver enough torque, computer speed, back ground programs running so the list could go on and on.

To answer your question. The JOG.FIL file only reads once when you enter jog mode and again when you leave jog.

It should be much better than what you describe.

My boss said we'll give you a free jog stick when you decide to upgrade.

Tech Support
CamSoft Corp.
(909) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

[HuFlungDung]

Oh boy, free stuff!

I'll tinker with those settings and let you know what happens.

[HuFlungDung]

Okay, I've turned up the ACCEL/DECEL from 200,000 counts to 400,000.

But, the problem remains pretty much the same.

I did notice something, though. I tend to simply hold down the CTRL key, while pressing the arrow key. When done this way, the little joystick icon in the jog window tends to "stick one way". I have to hit the arrow key twice, which has the effect of returning the joystick to neutral, and then initiating another jog.
So even though the machine is quite a bit more peppy, the response is still slow to my keyboard input, unless I release both keys, and then hit both keys at the same time. (I like that even less than before because I cannot anchor my hand!)

When in ALT jog mode, the response is similarly slow, and unpredicatable, as to whether I will for sure get a movement or not.

As you can imagine, I am very frustrated with having to do these two key combos. It wouldn't be half so bad if that were simply removed, and all axis movements redirected to the number pad.

So, is there any reason why keyboard jog could not be overhauled? I don't understand the resistance to improving it. You see people complaining about the price difference between CNC Lite and CNC Professional, yet you think they will be glad to add the cost of an I/O card that they might not even need?

Is a joystick controller so much more advanced in functionality? I am tempted to upgrade if it somehow bypasses the limitations of what I am experiencing in the keyboard jog modes. Your online demo could be a bit more explicit, as in someone actually using one to run their machine, perhaps?

I've posted my jog file below, in case you can detect some reason why there should be this gawdawful hesitation in the response.

Is there any way to get the DECELSTOP out of the jog logic built into the exe? I have a hunch that is where the problem is. Maybe, a SMOOTH command needs to be inserted if many rapid keypresses are detected?

Thanks for your time and patience.

~@~JOG.FIL
'This logic gets read once when the jog icon is toggled on and once more when jog is toggled off
IF\555=1THENGOTO :BEGINJOG
IF\555=0THENGOTO :LEAVEJOG
:BEGINJOG
'saving relative position before jogging
MACHHOME1 \50
MACHHOME2 \51
SOFTLIMITS OFF
IF{\114+\115}<2THENGOTO :EXCEPTNOW 'skip the point save if machine is jogged during homing routine
TOGGLE 4;ON;PTSAVED :\220=1
LABEL2 POSITION SAVED IMMEDIATELY WHEN JOG+RET SWITCH FLIPPED ON;11
BUTTON15 IN; CLICK HERE, MACHINE WILL MOVE TO SAVED POSITION;0
:EXCEPTNOW
ACCEL 1;400000 ECEL 1;400000 :RAPIDSPEED 1;10000
ACCEL 2;400000 ECEL 2;400000 :RAPIDSPEED 2;10000 :LABEL1 JOGGING SPEEDS ENABLED :EXIT
:LEAVEJOG
ACCEL 1;101376 ECEL 1;153600 :RAPIDSPEED 1;\201 'jog off
ACCEL 2;101376 ECEL 2;153600 :RAPIDSPEED 2;\202 :LABEL1 JOGGING SPEEDS CANCELLED

(Damn smilies, but you know what they represent )

[camsoft]

We'll this is progress, but still something is still not set right. The jog icon shouldn't take two keyboard clicks to snap back either.

The CTRL key is slow jog and it's also slow to accel.

Now use the SHIFT key and arrow.
Anchor your left hand to hold down the SHIFT key and press and release the arrow key.

Next do the same jog with the ALT key and arrow key.

Go into demo mode and do the same things and tell us if the readout and jog icon response differently?

The jog keyboard works fine for most people. While it is not as snappy as real buttons or I/O based jog sticks, if it's not moving within a split second of pressing the key you have problem that needs to be solved.

The $25 USB jog stick is a popular item running on machines, but it still may take a split second to move too, but it offer 11 functions that only a digital I/O card can duplicate. You get real buttons to press, that are all user customizable without buying a digital I/O card.

That's some JOG.FIL file. Nothing to add.

Yes, using the USB joystick just like a real I/O joy stick or physical jog buttons you can program out the DECELSTOP.

Hopefully, we'll learn more when you report back.

Tech Support
CamSoft Corp.
(909) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

[HillBilly]

I believe it will be hard to get the response we are looking for through the GUI. The way the motion controller is a stand alone device with it's own instruction set and the GUI either detecting a button press or I/O change then coverting it to Galil to be executed if the servos are stable.

This is a ideal that should overcome this. A PIC microcontroller programed as a handwheel emulator. You could have 3 inputs, 2 momentary NO push buttons for + and - jog and 1 SPST for high and low jog. There would be two outputs A and B quadrature that would be sent to the aux encoder. The PIC would be programed with the motion parameters like Hu mentioned before or similar. The GUI would look at it as a handwheel and slave the requested axis to it. This may be worth it if you plan to use it on several applications but if just intended for one the handwheel will probably be just as cheap.

Darek

[HuFlungDung]

Darek,

Thanks for the ideas. But, I've got to see if there is any way to make it work right in Windows first
I find myself in a similar situation to the time when I decided I had to move from CNCLite to CNC Professional, in order to gain access to various logic paths which I needed to tinker with. Only in this case, there is no way to get at the built in jog logic, which is a pity. It could be made to work elegantly without more hardware (end of pouting session )

I am game for the USB jogstick, since it most likely runs from logic in the macro.fil? (hint this is a question )

I've yet to run that test with the demo cbk. If I don't post here before Monday, just wait longer

[HuFlungDung]

Hi guys,

Just trying to get to the bottom of this jog performance issue, I sent in copies of the cbk's I used.

Default_for_Graziano is the default cbk, with the following files added in, from my working cbk,
so that basic operation of the machine was possible without errors:
Limits.fil
Estop.fil
Startup.fil
Inputio.fil

When I did the jog test, I did not do anything except load the modified cbk, type in RISK, and go directly into the jog function, using the keyboard only.

The delayed action performance of the jogging motions in response to the pressing of the keyboard keys is exactly the same in both files, as far as I can tell. It hesitates, and seems to not want to move until both keys are released, and then both pressed again to initiate the next jog. And this all takes quite a bit of time, because if you do it quickly (not break-neck fast, but 3 or 4 taps per second), nothing is likely to happen at all, or you may be lucky, and one of the taps will register. Its quite exasperating, honestly, and has always been this way. Are you sure there is no room for improvement?

If anyone else actually uses keyboard jog in their Camsoft control, we'd like to hear and compare your machine performance in jog mode. I'm talking about short movements, such as you might do when trying to do a touch off. IMO, this should be entirely and rapidly possible to do, using the keyboard.

Thanks
Murray

[HuFlungDung]

I'd like to touch on the safety issue of the two key combo controls for keyboard jogging. If this is truly superior for safety, than this implies that all users would be incorporating the same sort of two key combos for jogging on their handheld pendants. Anyone want to make a wager that this is actually the case?

While I appreciate the concern for safety, I do not rate safety above usability, which in this case, I fear that usability is greatly hampered by the two key combo. Of course, one must have his wits about when jogging a machine. But, in actual usage, trying to remember if I should be using CTRL+key or SHIFT+key is in itself, the source of error! That is not conducive to the safety which it supposedly enhances.

There are lots of other ways to "add safety", without encumbering the gui. For example, the jog window itself could easily display "Hi Jog Rate" Lo Jog Rate" etc, just as I have done with LABEL.

I suspect that part of the Camsoft resistance to modifying the jog logic, moving it over to the numpad as I suggested, is due to the fact that the same executable is supposed to run 8 axis. There is obviously not a good facility on the numberpad to handle more than 3 axis, unless you begin to name axis letters as we do now.

However, since 3 axis machines most likely represent 99% of the usage, I would suggest that perhaps a version, "CNC Professional for 3 machining axis" could be maintained with the jogging functions on the numpad, as described earlier.

Now, I'm not asking Camsoft to write all the specific logic. I believe that a more general principle to enhance the whole gui, would be a "game style" key-binding facility, which would allow users to make full use of the keyboard's built in I/O for much more custom usage than we currently enjoy. Isn't this sort of programable keyboard already part and parcel of DirectX anyways?

[HillBilly]

Hu,

I can tell you on the two OEM's I am involved in with pendants you can not tap tap tap the jog button on the pendant either. There is a split second delay that keeps you from doing this. I will go on to add these systems have brand new Yaskawa servos tuned by the local Galil/Yaskawa rep (which is Bertel Camp Automation in this area.).

If you have a spare input on your Galil it would be worth testing a single jog button with I/O logic. At this point you could do a Galil program to look at this input and initiate a jog. The Galil test should be a good indication of what the GUI has available to it.

Darek

[camsoft]

Murray,

We see what you're saying now. We got your CBK file and explanation.

All this fuss. We didn't realize you were expecting to tap on the keyboard 3-4 times per second. That's not going to work through keyboard jog. A split second delay is to be expected. You should think about one of the other jogging methods. Like Darek mentioned an I/O point is more responsive.

We don't have access to your purchasing records, but didn't you recently purchase a Handheld controller and digital I/O board from us?

If so the handwheel jog is the answer. Response, distance and jogging speed are all user settable.

To Hillbilly (Mr. Darek Ashburn) from the tech staff here at CamSoft, apology accepted. My boss is still pretty hot under the collar and lets hope we avoided something neither one us want to go though.

Tech Support
CamSoft Corp.
909-674-8100
support@camsoftcorp.com

[HuFlungDung]

Camsoft,

Yes I did purchase what you described, but that will be for my mill retro coming up in the near future (I hope).

I still don't feel inclined to sink hundreds of dollars adding extra I/O to my lathe retro.

Perhaps your USB jogtick might work well on my lathe? Maybe you can predict what kind of performance (compared to keyboard jog) I could expect using that input device? If I recall correctly, when using some sort of an external jog interface, I would simply turn off (disable) the Jog Window altogether, right? Then all the jog logic becomes strictly whatever is written in the macro.fil, right?