Advanced Search

The basic motion I/O looks relatively straight forward

The A,/A B,/B, Z,/Z signals are encoder signals and go directly to the 7I97T

The Servo-Out pins go to the 7I97T analog out pins and the Servo-Out-Common pins
go the the 7I97T GND pins adjacent to the 7I97T analog out pins.

The drive enables are a bit more puzzling as It hard to tell if they are activated by grounding
or supplying a positive voltage 

 

Homing configuration is in both the hal file (index and home switch handling) and the ini file
(type of homing, directions, speeds etc) 

linuxcnc.org/docs/html/config/ini-homing.html

what do you mean by a configuration problem, in a .hal file?

OK - I don't know how this got so 'catty wompus' but... turns out - it was my stepper setting. Originally - it was 8000 steps /inch. which seems to be what was in my 'backup' .INI. When I checked my step setting and did the math - I realized it should be 4000 steps. That improved the movement, but I was still getting 'follow errors' (or something like that). One thing I DID notice is - I was out by a factor of 2 when I did a G0 X.5 command. I went back to 8000 and suddenly I was out by a factor of 4... oops - wrong direction. Changed to 2000 steps/in and all my errors have gone and I am able to use the machine again.

I have to confirm yet - but I'm using a chinese 'blue' board parallel port controller and I'm wondering if my stepper switch settings are documented wrong.

Anyways - crisis resolved. Thank you for your help - this discussion can be closed.

Hi again,

The bug has been found in the driver. It was indeed not counting correctly resulting in trying to overflow the buffer (that caused an abort without writing beyond the buffer). I will be making a patch for it tomorrow.

Also, the mrje70a device is something of a piece with very complex modbus communication (I downloaded the comms spec). It seems to use "record reads and writes in depth" where several values are read/write from an address in a structure like fashion. These must be read/written using a single modbus transaction (when the "continuous read/write" column set to "impossible" it seems to denote that it is a record read/written in depth and not by incremental address). That is the first time I've seen such a hack. Luckily, the driver can do that (but you need to ignore the misalignment warnings from mesambccc). However, some extra pin setup is needed before you want to start writing or you will be sending half or malformed data. I'll show how to do that when I have made the patch.

All that said, the patch will also include a fix for the completely brain-dead mrje70a communication, where it returns a single signed byte (!) in a word register's LSB and zeros the MSB while leaving the user the hassle to tackle the sign extension. The patch will allow you to perform the proper sign extension to s32, s64 or float hal types by introducing a byte type.

slowpoke wrote:

Aciera wrote:

I have not used the anglejog component other than playing around with the sim config. As I understand it the 'scale' factor is used to avoid stair stepping in the tool path. Maybe the original discussion can give you some more clues:
forum.linuxcnc.org/38-general-linuxcnc-q...mode?start=10#253252

[edit]
I would tend to use the default values used in the sim config and adjust the
'max_vel',  'max_accel' pins (and possibly 'accel_fraction_in' for fine tuning) 
Thanks for your help. I should play with the sim config, I'm not sure how to do that?

Okay, figured out what I was doing wrong (anglejog.N.iscale-factor), so I now have angle jogging working.

Thanks for all your help!

I was generating the bit string backwards which only worked right if all output types were the same. I just fixed that with PCW's help. The inputs and outputs hal has just been fixed as well.

JT

OK that means that index is working as expected, so if homing
to index fails, its likely a homing setup issue.

Another remark.. not sure if that me misunderstanding anything or if its another bug, but witih MesaCT I generated a config to set my outputs 0-7 to sinking and 8-15 to sourcing.
This were the generated lines:
setp hm2_7i76e.0.7i76.0.0.output_sink 0xff00
setp hm2_7i76e.0.7i76.0.0.output_source 0xff

isnt this "the wrong order"? imho this sets 0-7 to source and 8-15 to sink.. right?

Yes.  Here is a schematic that goes from the interface PCB to the hypertherm microedge for the drives.  I'm only familiar with stepper motors at this point so this is a little overwhelming.

Thx JT for the quick reply!

Hello again, it's been a while. I'm now back working on the lathe machine. I connected the Modbus to the X and Y axis servo motors and also to the spindle – all working fine. I can read the load values from the servo motors without problems. But there is an issue with the spindle load display. Sometimes it shows too many zeros after the decimal point. I tried to fix this with Python code to cut the extra zeros, but I couldn't make it work. Has anyone had this problem before?
What is the easiest way to fix it?

 



 

so I tested it and switched the red button to yellow. and it turned red at the same position when I turned my encoder.

setp [HMOT](CARD0).encoder.00.index-enable true

This is wrong and should be removed

Also: Is the encoder position cleared to 0 when you set b-index-enable?
(set in the halshow:watch tab)

I am not sure what you mean by simulate the auto tool config.

Is that in a simulation config? I have never messed with those.

Sorry to be such a neophyte.