Advanced Search

vre wrote:

How you will implement this because
raster engraving with mesa not supported to linuxcnc.

That is not correct, i use LinuxCNC with and without Mesa for engraving and it works perfectly.
forum.linuxcnc.org/show-your-stuff/46752...ver-etcher-scratcher
Configs should be attached there, and yes, it is the same thing as laser, it uses PWM for pressure control.

Hi, 

after a few month working with my bread board set up, I am continuing to build up a PCB board. The pin connection is currently all over the place, but it works... I am cleaning that up and have a quick question about the Tang Nano 9k. I am palling to use Bank 1 and 2(3.3V) for the input and outputs. I don't need to use Bank 3 (1.8V) as my machine is not that complicated. 

Are all Pins from Bank 1 and 2 usable as Inputs and Outputs or are there special pins which need to be high or low at boot?? Similar to some Microcontroller?

Do you want galvo for engraving?
How you will implement this because
raster engraving with mesa not supported to linuxcnc.

Just one more thought...

Is it necessary that the write command has pins? Does this data change real-time?
There are several side-effects to this being pins that can change. For example, the documentation lets on that it needs to be written as *one* modbus transaction. (that would mean I first need to fix the bug)

These parameters look like initialization values you set once and leave the same. If that is the case, you can simply make it a single command writing the necessary registers in the <initlist> in one command writing the 5 registers with static data/values in one transaction.

Hello, (author of the hm2_modbus driver calling...)

First, what is the error code generated? See the hm2_modbus.0.command.NN.error-code pins.

Second, what LCNC version are you using?

Just a comment on the attached documentation image:
Reading and writing registers are, in modbus terms, always multiples of word (2-byte) quantities. The image with the "Home position return speed" at register address 0x6099 states a /single byte/ and then two 4-byte words. The documentation is slightly misleading. It states in the next column that 5 registers are actually involved, so that would indicate that the first is masked to a byte sized value (masking is not supported or performed by the hm2_modbus driver). The 5-register statement in the table would also fix the problem of having 32-bit words seemingly on a odd address boundary. But with 5 registers, then the "number of entries" value is at address 0x6099 and the two 32-bit words are at 0x609a and 0x609c resp.. BTW, I notice the interesting mixed endianess of the 32-bit values...

The read operation seems to work as intended, but the write operation fails. The failure is apparently not a problem of the mbccs file. It is an error message of the hm2_modbus driver that indicates something odd is happening.

When compiling the mbccs file I get a couple of warnings (using first file below):
mrje70a.mbccs: warning: Multi-register type 'U_CDAB' not aligned to natural boundary in commands/command[1]/pin[2]
mrje70a.mbccs: warning: Multi-register type 'U_CDAB' not aligned to natural boundary in commands/command[1]/pin[3]
mrje70a.mbccs: warning: Multi-register type 'U_CDAB' not aligned to natural boundary in commands/command[2]/pin[2]
mrje70a.mbccs: warning: Multi-register type 'U_CDAB' not aligned to natural boundary in commands/command[2]/pin[3]

But, that should not be the case. This is an error in mesambccc not being able to count correctly. Using the --verbose option clearly shows the address to be even. I have to investigate and see what is happening. I am guessing that the hm2_modbus error is secondary to an error in mesambccc when setting the command and pin fields for the command lists. As a temporary fix: splitting the read and write commands into two separate commands makes the warnings go away (second source below). It /might/ fix the read/write issue you are having. The downside is that the read/write no longer is one single modbus transaction. That may or may not be a problem, depending the device.

The way you wrote the definition should work. I'd write it like:
[/code][/code][/code][/code]

The timing problems are probably due to combining a ebay no-name torch with a aliexpress no-name inverter, and then unplugging the HF start from the inverter as it caused too much interference. But it runs good enough for our use when the torch gets its needed recovery time between starts.
I'll consider modifying the post, but I'll also take a look at the plasmac component to see if I can tweak it to do it like our MACH3 M3 macro does.

Main thing is that MACH3 seems to have some problems blending moves together.
Our table is multi function and currently it is setup with a LED laser cutter head and at the speeds needed for that we could better see the lack of blending.

The second part is that it would be nice to have all the cut-recover features from plasmac.