Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
ModeratorThis is just a guess:
Did you hand edit the {“zsn”,0} JSON command into the Gcode file (to turn off the limit switch) ?When the GCode is being sent, I believe tinyG is in text mode.
Try inserting this
$ej = 1 //switch to json mode
{“zsn”,0}
{“ej”,0} //back to textAs I said, a guess on my part, have never actually done this
Or, maybe, just replace you json command
{“zsn”,0}with same command in text mode syntax
$zsn = 0ModeratorBummer.
Surge events can lead to difficult/impossible to find problems.
ModeratorI imported your nc file to a CAM simulator, looks OK here too.
Good data set, I’ll refer it to the developers
Have other jobs run OK on your setup?
I’m curious – what is the A axis’ role here?
Not that it should matter in this instance.ModeratorGuido
First a Forum Comment: You started this in the tinyG/TinyG Feature Requests sub-forum. Now that I see where you are headed, I believe you should be in the tinyG/TinyG Support sub-forum. It is likely that more active developers, like yourself, will see your posts and respond. This sub-forum is sort of a wish list for future features, the Support sub-forum is for “how-do-I-make-it-work”. I suggest you continue there,Your project: I believe your description of an implementation of Xon/Xoff protocol is a good one. BUT it implies to me that your environment on the PIC32 has minimal ‘driver’ like support for peripherals, since flow control, buffering, etc. are usually handled by device drivers. Your approach seems correct, but readers here can only assume that your implementation has also considered any possible error cases and recovery from them.
Have you run your CNC via a terminal application running on a PC under Windows (or Linux, or MacOS)? A very typical environment that most here understand and use is Coolterm on Windows. Running some test Gcode from that platform will reveal the steps necessary to Run a complete job. In general, you first need to configure tinyG with tinyG specific configuration commands(such as setting the Flow control to Xon/Xoff, or RTS/CTS, or….) and configure tinyG for specifics about your machine (motor setup, axis setup). All these steps are covered on the wiki, start here
I continue to believe you can implement your PIC based machine controller, but I am not sure you have a grasp on all the steps necessary for success. Since there is no detailed how-to to guide you, the experience you would gain from running a complete (successful) job via Coolterm would seem a hands on introduction to the complete process.
For most folks here, running tinyG from a terminal is the “lowest level” interface and most work with higher level applications such as tgFX or Chilipeppr or JCNC.
Many folks have coded their own implementations, but you are really on your own to understand all the pieces of the puzzleWhen you continue, I do suggest switching to tinyG Support sub-forum. You will attract more input there.
ModeratorInteresting, report this to John Laurer over on the google groups forum.
He may be able to identify for you.ModeratorI’ll say the answer is yes, since tinyG simply receives and responds to tinyG Commands and Gcode received via USB or serial (via the serial headed pins).
As you can imagine, flow control is essential.
Also good to observe the tinyG response stream as it is working on your data stream.
If you wander thru the forums a bit, you’ll see several folks developing their own Applications which are similar to tgFX
Also have a look at the Q&A and Comments onThere is no detailed how-to, but all the raw data seems to be available.
ModeratorHead over to
-
where Chilipeppr is spoken more fluently
ModeratorYes, others have reported that tgFX build 3625has issues with doing tinyG updates.
Happy cutting, errr, lasing.
ModeratorI don’t see a connection for the per-driver Enable signals.
That may or may not be important in your application.ModeratorGood news that something works, but I am not at all certain what it is that is working:
You are running tgFX build 3625.
Did you update to tinyG 438.02, or stay with 435.10?It is possible that communication/flow control issues are at play if you stayed with 435.10. tgFX was the outgrowth of tweaks to make tinyG 438.02 and tgFX cooperate well
Resource issues are incredibly hard to understand, but I will comment that I have seen tgFX run ‘OK’ (whatever that means) with CPU pegged at 100%.
I quickly ran your .nc in a simulator; nothing immediately obvious.
-
This reply was modified 10 years, 2 months ago by
cmcgrath5035.
ModeratorI have not tried any external drivers yet, but this thread
reports measure pulse widths of 4us with tinyG FW 438.02, so that part of the puzzle should work for you.
Moderator$$ is for sure a good place to start(well, continue actually, since you have a really full list already), but I don’t believe it would be the complete list.
I would characterize $$ as representing the parameters the developers are comfortable with user’s tweaking with ‘acceptable’ risk. This is a guess on my part.
When Alden checks in and speaks, you will know you have the full list.ModeratorI did a little Googling on proximity switches, saw a hit relative to Arduino and proximity and looked about there.
First, here is a good reference diagram for interfacing to an Uno (5V logic), for Due and tinyG, Repalce Arduino +5V with Arduino/tinyG 3.3V
I now better understand what these are – sort of neat and should be good for your proposed application.
I saw at least one diagram that provided this info:
Sensor is a 3 lead device: Vin, Vout and Gnd.
An NPN (NC) proximity sensor has an NPN transistor output stage, which in the case I saw was pulled high internally to the Vin by a 10K resistor.So, if you supply 6V on Vin and provide no load on Vout, the device will switch between Gnd and 6V, depending on the magnet position.
If you connect a 10K resistor from Vout to GND, then the device would switch between GND and 3V, with the internal resistor and the added 10K making a 2:1 voltage divider.You’ll need a source of 6V or greater, perhaps use 12V fan voltage from tinyG and modify your voltage divider accordingly.
There is no guarantee, without deeper research, as to what the internal pull-up for a particular sensor would be, but I think you can easily experiment to figure out what it is from the above.
So you could use just this voltage divider approach, or implement 6 of the Method 1 or Method2 interfaces for maximum protection.Since this is a rather common problem, and you have 6 inputs to deal with, look around for a likely available 6 or 8 wide translator device, I bet they exist, don’t have time to look at the moment.
ModeratorCan you provide a link to a typical inductive switch? I’m not sure what you are referring to.
If the switch outputs gnd(NC) or 6V, then a simple 1/2 voltage divider between the switch output and the tinyG input should work.
But first I’d like to understand where the 6V comes from.ModeratorHere is just an example of an industrial noise filter
They are numerous on ebay, relatively inexpensive; removed from decommissioned machines I assume.
Tolkin is one of many suppliers, Google around a bit and you’ll find a catalog.pdf. You have to buy for the right voltage, current and single/3 phase.I bought and installed one of these last year for my AC Blower, an electronically controlled torque motor. I am suspicious that my TIG Welder, with hi frequency arc-starter, took out the electronic controls.
TIG draws 50A, those were hard to find, but motor sized filters were plentiful. -
This reply was modified 10 years, 2 months ago by
-
AuthorPosts
