Hello Guest it is December 06, 2021, 11:56:00 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Dubble

Pages: 1 2 3 4 »
1
THC is not only time critical, but that whole control is handled directly by the motion controller because Mach and Windows is not realtime and THC control has to work instant.
The UC400ETH implements THC control and ethernet is much better than USB for electrically noisy applications like plasma control, because ethernet is isolated while USB is ground referenced.
So, using a UC400ETH is a good solution.

2
Yes, you basicly told the same what I said, but the UC100 is a motion controller board and the OP is talking about connecting 2 of them is what I was answering to.
For non time critical signals it might be not a problem using a separate board to handle those signals other than the communication delay, if that is not a problem for a non time critical signal then there is no problem,
but the UC100 is not a board to handle auxiliary signals, it is a motion controller with a motion control plugin, so it works as a motion controller.

3
Guess what happens if you using 2 devices connected to one computer with the same software.
The main problem is Windows and so Mach is not realtime, so both controllers will have a communication latency and have to use buffered communication to work quasy realtime. Realtime at least to themselves and giving the illusion of realtime working to the user.
So, you have 2 controllers then guess what happens when you configuring a home input to one device and configuring the axes motion to the other device.
When device 1. gets a home input switch trigger when the axis reaches the home switch then device 1. can't interact directly on the signal, because it is not the one in charge for the axes movements, but device 2. is.
Now what device 1. can do is it informs the software on the PC. Now this is one delay, because to send the data out and to receive it takes time.
Now what the software can do is it can send a signal to the motion controller telling it that the home movement has to stop, because the home switch was reached. Now this communication is a second delay.
These 2 delays add together, however even one delay could cause a crash of the axis, because if the speed of the homing is high enough and the communications delay is large enough then the axis will already crash into the home switch or to the mechanical endlimit before the controller device 2. would even be notified about the home switch reached event.
This was just an example, it could be told with other signals too, like limit switches, probes etc.
Also what if one device disconnects and has to tell the computer to stop the motion and the computer has to tell the other controller to stop motion, because there is an issue with the other controller.
What if the other controller implements disconnects incorrectly and the computer side software does not even know about the disconnetion while important signals are configured on controller 2.

So, using 2 different controllers to handle signals is very unsafe in my opinion. I think even the concept of handling signals like that is dangerous.
The only safe way I see is to handle all signals on the same controller and then that controller should have as many I/Os as required for the application and that one controller should handle time critical signals directly and only when the event is handled it can notify the PC side software letting it know that this and that happened, so there is no delay at all in handling these type of signals...

4
General Mach Discussion / Re: Can not reinstall Mach3
« on: September 28, 2017, 07:39:43 AM »
If it did not require a USB driver then it is not a UC100, but a chinese fake controller.
The UC100 requires a USB driver to be installed, but our UCx00 automatic installer application available for download on our website takes care of installing both the USB drivers and the plugin.
With the chinese controller you don't need to install a USB driver, because it works as a HID device, so the driver is installed in the OS which can only throughput 64kb/sec data max., so it is far slower communication as what the real UC100 does, and so the motion path will have a much lower resolution, because the speed update loop can be be about 8 times slower than it is with the real UC100.

5
Mach4 General Discussion / Re: Mach4lathe - Not ready for prime time
« on: April 28, 2017, 10:21:18 AM »
Or maybe we using a version which has a problem. Will try some other newer versions soon.

6
Mach4 General Discussion / Re: Mach4lathe - Not ready for prime time
« on: April 28, 2017, 10:20:07 AM »
OK, thanks for the info. Then we doing something wrong when calling the thread function in M4.

7
Mach4 General Discussion / Re: Mach4lathe - Not ready for prime time
« on: April 28, 2017, 10:04:54 AM »
I'm not 100% sure now since your video is no more available on youtube, so I can't verify, but if I recall you zoomed on the g-code view section of the screen so I did not see that it is the lathe version of mach4.
I realised it is M4lathe only when you've mentioned it in a later e-mail and then all became clear and I informed you what the problem is.
So, I just wanted to make it clear that you did get the information when you got it because we realised the issue only after a few more e-mails from you and not because you've posted anything on any forums which was suggested to be what happened.

"It would seem to be a good business practice for you hardware vendors to provide NFS with your hardware so they can test these kinds of issues?"

NFS got one or two UC100 a long time ago, so they have the hardware to test with and as far as I know they have tested them.

"A lathe without threading capabilities is like a blind man, there are many things that he can still do but he can only read books in braile."

Yes, I totally agree. And I still advice to not to use the UC100 with Mach4lathe eventhough the issue you reported was resolved.

"One of the first things that I did after buying the PMDX 411 is cut an internal 27 by 1.5 mm thread to mount a timing gear to my lathe spindle, worked flawlessly.  Mach4 did not collapse to its knees."

Sounds good, then the ones who wants to use a lathe has the solution.
Is it cutting thread with encoder feedback? Or just an index signal?
Because our issue is that our firmware can cut very precise threads with encoder feedback and we only want to implement threading with encoder feedback,
because we have very good results with cutting thread using encoder feedback. Using just the index signal is vary far in precision since the system is blind between the indexes.
And so what issue we having is about encoder based feedbacked threading ... have not tried with index only, because we think it is unprecise, maybe that one works, we don't know, but not even interested...

"Then I go to the vendor and ask them if they can duplicate the problem.  Only when they say "it's not our problem" or I don't get a response at all from them, that I go public like this. "

I have no problem with that.

8
Mach4 General Discussion / Re: Mach4lathe - Not ready for prime time
« on: April 28, 2017, 12:44:51 AM »
Quote
I identified problems with the UC100 plugin and only after having gone public on forums did they finally admit that they had not tested it on Lathe and that it should not be used with Mach4 Lathe.

We did not "finally admit" and we did not tell you because it gone to public forum, this is totally not true.
We do not monitor this forum often and only saw your post well after you already got that answer from us.
And so I saw your post in the forum after our discussion and thought to post the information (conclusion of our discussion) in your forum thread to let others also know to not use the UC100 with Mach4lathe, because it will not work.

When you've emailed us with this problem first you did not tell us clearly that you using Mach4lathe, so we did not know why the problem is happening at you, we debugged the issue using mach4mill, so first we did not know what is going on, because we could not reproduce the issue with mach4mill which we have tested with.
After a few of your e-mails we've managed to put the puzzle together and realized that you using mach4 lathe and then we immediately let you know that it was not tested.
Furthermore we debugged the issue with mach4lathe when we realised you using it and then we immediately confirmed to you that it is not working and that we can reproduce the same on our system.

And the issue was by the way already corrected, we have tested the mach4lathe version afterwards you reported this issue and have managed to resolve it.
So, if you download the plugin from our website now it does not have the issue anymore, because that issue was already resolved weeks ago.

The only important thing our plugin does not support now in mach4lathe is the thread cutting, because however our firmware supports precise thread cutting we could not make it work with mach4, because as soon as we call a function to get the information about the thread mach4 collapses to knees and so we can't build an interface to it. It is just a guess, but probably the thread cutting is currently broken in mach4 or we doing something wrong.


9
General Mach Discussion / Re: Compatibility Test Diagnostics Failed !
« on: April 24, 2017, 07:27:27 AM »
Craig,

We have the Mach4 plugin for the UC100 about 3-4months now and we have ethernet controllers about 1.5 years or so.

10
General Mach Discussion / Re: Compatibility Test Diagnostics Failed !
« on: April 21, 2017, 06:16:33 PM »
Craig, just to clarify we "CNCdrive/UC********* devices" have a Mach4 plugin for our UC100 controller, it's available for download on our website.
And we also have ethernet controllers (UC300ETH and UC400ETH), but still working on the Mach4 plugin for these, they yet have Mach3 plugin only.

http://cncdrive.com/UC300ETH.html
http://cncdrive.com/UC400ETH.html

Pages: 1 2 3 4 »