- FineLine Saturn 4x2 with ClearPath, UC300-ETH / MB2

[DDgitfiddle]

Robert -

I tried this connection scheme tonight and it didnt work. I believe the problem is the EA input wants to see a pulse stream with positive polarity. So sourcing (?) outputs from a control board may work... Anyway, I went back to using the C axis Step+ and Step - CSTP+ to EA and CSTP - to L. I emailed Weerasak to let him know.

Hmmm...that's a bummer. Thanks for letting me know.

FWIW, I contacted Hitachi yesterday, and their tech support indicated that the EA input is rated for 5V - 24V.

Actually, I just thought of an idea. If reverse polarity is really the problem, did you try reversing the polarity in UCCNC? Not sure if that is possible with how this gets set up for pulse train control in UCCNC, but that might be an option. I have had to do that for a number of my I/O.


-Robert

[DDgitfiddle]

The Hitachi manual(s) are indeed lacking in info on using the pulse train input mode. I have seen both the 10V and the higher spec for PT EA. I use the 10V spec. A while back I did some amplitude tests on the pulse train EA input and found that around 5V (don't recall exactly what the number was) the PT mode stopped working. So, it looked to me like using 10V had good margin. As an aside, I always isolate all input/output signals between the BOB and VFD. I used an optoisolator (of appropriate bandwidth) on the BOB side to drive EA. I used the 10V reference voltage (good for 10ma I think) that the VFD provides to pull up the collector of the optoisolator using a 2k or so resistor. I've looked at the 25K Hz PT at the VFD end using this scheme and the signal looks good and is stable. Of course, mileage may vary.

Frank

Frank,

This is looking like a decent option right now. Do you have an optoisolator that you recommend?

Thanks,
Robert

[ger21]

Why don't you guys just use Modbus like everyone else?
http://www.cnczone.com/forums/uccnc-...n-uccnc-2.html

[DDgitfiddle]

Why don't you guys just use Modbus like everyone else?
http://www.cnczone.com/forums/uccnc-...n-uccnc-2.html

The short answer (originally) was that I didn't want another cable running from my laptop to the control box. I had tested the pulse train option before finalizing the wiring and it worked, but I've obviously introduced a problem since then. I will take a look at the Modbus option again and see what it takes. It would be nice to be able to run everything through the main controller. Maybe I am missing something here.

-Robert

[ger21]

If you are using a laptop, then yes, the extra cable might be problematic. I've been using my laptop with my test board, and it's fairly easy to bump the modbus cable loose.
I'd never use a laptop to run my machine, though. Too much dust in the shop.

[1Jumper10]

Weerasak gpt back with me. He was glad the pulse stream from the axis line driver was working but he had a reservation about connecting it that way because with that method there is no isolation between the VFD and the UC300ETH. He sent me a connection diagram using a 1K -3K ohm resistor between the EA and 24 terminals on the VFD and using the Y301 output for the pulse train. I'll try it tonight and let you know. I hope that it works.

I'll have to check the Hitachi manual but I believe the inputs on the VFD are isolated.

[ger21]

And then there's always analog control, which is built into the MB2, and doesn't require additional cables to the laptop.

[pontoonman]

Frank,

This is looking like a decent option right now. Do you have an optoisolator that you recommend?

Robert,

I am using an On Semiconductor (Fairchild) H11L1M through-hole optoisolator. It's cheap and readily available.

A few comments:

1. I will be interested to hear if the Hitachi EA input is isolated. I assumed it wasn't and used the H11L1M isolator on the BOB end to provide isolation and to allow for the use of Hitachi supplied 10V as my signaling voltage. As I stated in my post, I believe it to be good practice to isolate all input/output signals between the BOB and VFD.
2. As Ger suggests, using the PWM-to-analog (0-10V) converter that is on your BOB is a good alternative as long as it's circuitry is isolated via a DC-DC converter (I don't anything about the MB2 BOB).
3. Modbus is indeed another option and one that I implemented as an experiment with good results. As you say, it does add another cable, and in my case an adapter card too. Then you need to develop the software and maintain it. If you want to get all kinds of info from the VFD, it's a good way to go. But for me, it requires to much stuff to just control the speed when compared to the other approaches.

Good luck!
Frank

[ger21]

3. Modbus is indeed another option and one that I implemented as an experiment with good results. As you say, it does add another cable, and in my case an adapter card too. Then you need to develop the software and maintain it. If you want to get all kinds of info from the VFD, it's a good way to go. But for me, it requires to much stuff to just control the speed when compared to the other approaches.

I posted a link to a thread with a generic modbus plugin for UCCNC, which greatly simplifies setup and use of modbus.
I use a Huanyang plugin by the same author, and it couldn't be more simple. Takes about 1 minute to setup, and you can forget about it after that.
And, it works with a $7 USB adapter. But when I get around to using it on a machine, I'll be using a PCI card, for better reliability.

[1Jumper10]

This set up worked. I tested it tonight. Instead of the 1-3 k-ohm 1 watt resistor I used a 5.5k-ohm 1/2 watt. I ran the spindle for about 10 minutes and it was stable and responded quickly to different speed commands. I kept checking the resistor to see if it was getting warm and it never did. It should be reliable and it isolates the VFD electrically from the UC300ETH.

Weerasak at CNCroom helped me with the circuit. A simple 1 cent resistor was all it required. Except of course for the knowledge necessary to put the resistor across the right places. That education cost me an MB2 board.

[DDgitfiddle]

This set up worked. I tested it tonight. Instead of the 1-3 k-ohm 1 watt resistor I used a 5.5k-ohm 1/2 watt. I ran the spindle for about 10 minutes and it was stable and responded quickly to different speed commands. I kept checking the resistor to see if it was getting warm and it never did. It should be reliable and it isolates the VFD electrically from the UC300ETH.

Weerasak at CNCroom helped me with the circuit. A simple 1 cent resistor was all it required. Except of course for the knowledge necessary to put the resistor across the right places. That education cost me an MB2 board.

Thanks for the update! With a 5.5K resistor, you would only get 4 mA of current and a little more than 0.1W of power. The 1/2 watt resistor would be fine. It seems like it would not be necessary to to connect the MB2 24V to the VFD PLC line. The VFD would act like an external 24V supply, and supposedly that is OK for the MB2. P24 and PLC are connected in my system (VFD Sinking input logic). I am using one of the relays on the MB2 as the VFD RUN signal, so I need the VFD to provide 24V. I would think that connecting 24V from the MB2 to EA through a resistor would also work. I'll give that a try also. I need to dig around and see what sorts of resistors I have.

-Robert

[DDgitfiddle]

If you are using a laptop, then yes, the extra cable might be problematic. I've been using my laptop with my test board, and it's fairly easy to bump the modbus cable loose.
I'd never use a laptop to run my machine, though. Too much dust in the shop.

The laptop was available for cheap (free) so we'll see how long it lasts. Someday, maybe I'll mount a small motherboard inside the main enclosure and try to run on a small Solid state hard drive. Eventually I would like to implement MODBUS, but I have a ton to learn about actually programming a CNC and making wood chips first.

-Robert

[DDgitfiddle]

Robert,

I am using an On Semiconductor (Fairchild) H11L1M through-hole optoisolator. It's cheap and readily available.

Thanks, Frank! I was looking at DIN rail mounted optoisolators and they were definitely NOT cheap. I'll see if I can figure out a clean way to integrate one of these. I tried pretty hard to keep the logic isolated from the stuff that produces noise by using separate 24V power supplies, so a little extra effort here probably makes sense.

Thanks,
Robert

[pontoonman]

Thanks, Frank! I was looking at DIN rail mounted optoisolators and they were definitely NOT cheap. I'll see if I can figure out a clean way to integrate one of these. I tried pretty hard to keep the logic isolated from the stuff that produces noise by using separate 24V power supplies, so a little extra effort here probably makes sense.

Robert,
Disclaimer: I am not familiar with the MB2/UB1 BOBs, so I may be wrong about some of its specific specs. But from what I can see from the UB1 manual and the working solution 1jumper10 presented, you are good-to-go. That is, the Y30x outputs are already isolated using on-board optocouplers. Essentially, this is the same scheme I use except that I use the Hitachi 10V reference output rather than its 24V output to pullup the resistor connected to the BOB's optocoupler collector. The fact that the spindle runs at the appropriate rpm and appears to be stable is good news. If you want to take validation a step further and have access to an oscilloscope, you could look at the signal at the VFD EA input pin to make sure you have a nice clean pulse train (without obviously long rise and fall times or excessive noise) when running at the highest frequency (24k HZ?).

Anyway, it looks like this issue is behind you and 1 jumper10.
Frank

[DDgitfiddle]

Frank,

Thanks for looking into that. My stock of resistors is pretty pathetic right now, so I had to order in an assortment. Once that arrives, I'll give this a try and hope that it solves my original problem.

Thanks,
Robert

[DDgitfiddle]

I tried the circuit that 1Jumper10 posted, and had no luck. I seem to have a different problem. While trying to debug this, I converted the VFD back to manual control (fixed frequency, start using the VFD keypad), and I am still getting E30.4. A few times today, I also got E30.1 and E30.2, but my understanding is that the number after the decimal just indicates when in the cycle the error happened. I need to think through all of the changes that have happened since I was able to get the system running and try to figure out which one(s) are possible culprits. First key will be to get it running manually, then try to work out controlling it from software.

On the positive side, I figured out how to improve the three-handed reset problem. I was using the HLFB signal from the ClearPath motors to trigger the OSSD signal on the MB2, then also using the OSSD signal in series with the E-stop. The result was that the HLFB signal dropping out would cause an e-stop (cutting power to the motors). The HLFB signal can only function when the motors are enabled, the motors can only be enabled when they are powered up (i.e., no E-stop), and the e-stop could only be cleared when the OSSD signal was closed (i.e. HLFB signals all closed.) The solution was to pull the OSSD signal out of the E-stop circuit and use the HLFB signal to trigger a reset in UCCNC, thereby dropping the enable signal to the motors and spindle. On power up, the safety relay has to be reset (with a hardware button) but that can only happen when the Charge Pump is active (i.e. UCCNC is running). UCCNC will only reset (software reset) when the safety relay is providing power to the motors and the HLFB signal will come back.

Now to figure out the spindle.

<<<EDIT>>>
I figured out the problem. I'm surprised it could have possibly happened, but it did. Somehow, I managed to connect the spindle connector to the spindle the wrong way. It was rotated by 90 degrees, so that all of the connections were wrong, and most importantly, the ground wire was connected to one of the phases. This is a keyed connector, but somehow I was able to connect it the wrong way.

The only way I found it was to keep peeling back the various settings on the VFD until it was pretty close to stock configuration. Eventually it started giving me errors when it powered up, and eventually it gave me an E14.1 (Motor ground fault). I checked continuity from each of the phases to ground and they were all shorted. When I unplugged the cable form the motor, none of the phases was shorted to ground, so the problem was at the motor end. I checked for shorts from pin to pin on the motor, and it all seemed OK. I went to reconnect the motor and realized I was having to twist the cable more than I had to previously to get it connected the right way. I reconnected it the right way, and everything worked.

So after I reconnected all of the signals, I can now report that UCCNC is controlling the spindle as it should. The circuit posted by 1Jumper10 in post #110 works for me. It is important to connect 0V to the "L" terminal because it serves as a ground reference. I didn't do this at first, and the spindle surged on acceleration. After connecting this, it is very smooth.

So I'm back in business. I ran a very quick gantry squaring program (drills 4 holes in a square pattern) in the air without the spindle running, and everything worked. Running that for real will be the first real cuts on the system...hopefully later this week. Then we'll see how square the gantry is.

-Robert

[DDgitfiddle]

After a few weeks of waiting on little pieces of this and that, I finally put the finishing touches on my build this weekend and made a very small amount of dust. I am currently on a steep CAM learning curve using Fusion 360, so that has taken alot of my free time. This weekend, I added some cross bracing to the frame to try to make it a little more sturdy. It had a little more wiggle than I wanted. After that, I tied up a few of the prox sensor wires that had been dangling under the machine and then finally got around to running the gantry squaring program.

Maybe not the right forum for this, but I'll put it here for completeness on the build. I ran into a few small problems with the UCCNC post-processor for Fusion 360. While I was running my first program in open air (without a bit), I noticed that the Z-axis would rapid to a very low position then moved to the location for the first hole. If I had been running with a bit it would have crashed hard. It did the same thing at the end of the program. So I looked at the G-code and found a line "G0 G53 Z0" (Rapid move to Z=0 in Machine Coordinates) close to the beginning of the program. I have set my system up with the origin in the front left corner so that the X-axis is the gantry (about 2' long), The Y-axis is the dual motor axis that moves the gantry (about 4' long) and the Z-axis has its zero at the bottom of its stroke. This is a traditional mathematical coordinate system, and seems logical to me. I'm not sure why the post processor would send the system to what would seem like an unsafe position for its first move. Is my coordinate system convention non-standard for CNC? Should Z0 be at the top of stroke, and then require all negative numbers?

Either way, I managed to figure out how to edit the UCCNC Post-processor for Fusion 360 to send the Z-axis to a large positive value at the beginning and end of the program where it will be safe. I also figured out how to get the machine to pause for a few seconds to wait for the spindle to spin up so that it wouldn't start cutting too soon. Hopefully I won't need to get into there too much...there is alot of code that I have no clue about.

The last small quandary I have is on squaring the gantry. I ran the program to drill 1/4" holes in a square so that the holes are on 22" diagonals (on center). I put 1/4" steel pins in each hole and measured the diagonals. The measurements are just slightly over and under 22". I estimate that the measurements are maybe 0.020" - 0.030" different, or about 0.1 degree out of square. I'm trying to figure out a better way to measure the difference than eyeballing it with a framing square accurate to 1/8". It's pretty close, but I'd really like to have it as close as possible so I can rely on it. I am guessing I need to adjust one end of the gantry by about 0.04". I'm trying to figure out a way to do this repeatably so that I can zero in on "perfect". I also haven't tried tramming the spindle yet, and that could result in some shimming. Tedious, but worth it.

[ger21]

I also figured out how to get the machine to pause for a few seconds to wait for the spindle to spin up so that it wouldn't start cutting too soon.

In UCCNC, on the Spindle setup page, there are M3 delays that you can change to deal with this issue. You don't need to do it in the g-code.

[1Jumper10]

Glad to hear you got your spindle sorted out. I had missed your update.

I squared my gantry with a 3-4-5 triangle. And just as a side note if, you make the triangle with UCCNC but then measure the hypotenuse with a ruler, you will go crazy trying to get it square. That little excercise will definitely highlight the differences in measuring sticks. Anyway, once I laid out 5ft with the machine and measured the hypotenuse with that, I got it square. With the CP servos, you should really set up hard stop homing on the gantry. After the hardstop home is run, the servos will keep it square. And I think this will synchronize the servos so they don't try to fight each. I've yet to do this on mine as I need to make the travel stops but it's on the short list.

Sent from my Pixel XL using Tapatalk

[DDgitfiddle]

In UCCNC, on the Spindle setup page, there are M3 delays that you can change to deal with this issue. You don't need to do it in the g-code.

Thanks for the tip! I am still getting a little lost in all of the settings available in UCCNC. I will try to set that up and then remove the delay from the post-processor. I'm learning that there are alot of different ways to accomplish the same thing and not necessarily one way that is "best" in all cases. I agree that simplifying the G-code makes sense, though.

Thanks,
Robert