Forum Replies Created
-
AuthorPosts
-
moeterMember
Oh, yes, I’m confusing somehting myself here… Lot’s of input circuitry to get 24V active switches working. Anyways, that was setup correctly as NO. (I am using an elexol opto input board, tinyg is wired to the line transceiver directly they only use to drive the leds…)
The thing was, the latch backoff values were too small.
I’m still a bit sad that my suggested fix for this problem hasn’t been built into edge yet. I always have to compile my own version…
moeterMemberSome addition: Being in the Home Switch during startup seems to work, if it is configured as home switch only. So the limit switch state confusion seems to start when the limit switches are initialized.
November 3, 2014 at 3:41 am in reply to: JSON level 5 responses are hard to check for correctness #6964moeterMemberActually I’m not using a “real” JSON parser, because for security reasons I am not allowed to. I am building embedded software, that is controlling TinyG for using it as a more generic robot controlling system.
It’s kinda okay what it returns, and the list of precisions is helpful. But I still reckon it suboptimal, as these responses are the only way to actually check for comm errors, and identical strings would make this more straightforward and faster.
And actually I’m using an EDGE build (435.10) where I fixed this issue myself…
moeterMemberTried it with -0.99999, it’s working.
This keeps the line planning intact for angles down to 0.256°. I guess smaller angles can really be assumed to be straight lines for machines in our scale.
Actually, we could calculate the value where we can consider a junction as straight line as a relationship of the maximum speed, maximum jerk, microsteps and the mm/rev parameters. We may never exceed the maximum jerk in the duration of one (micro)step to assume the junction to be a straight line. I’ll try to put this into a formula, but this might be complicated…
moeterMemberFound it in the sources:
https://github.com/synthetos/TinyG/blob/edge/firmware/tinyg/plan_line.c#L494
-0.99 needs to be closer to -1. Something like -0.9999 should be sufficient, this would include all angles larger than 1°.
- This reply was modified 10 years, 3 months ago by moeter.
moeterMemberHm, but is it still power sequencing independent, if one would use the serial pins (J14) on the board?
And, is it safe to power the logic part on its own via one of the many 3.3V terminals and attach 24V to V_mot? I think this might destroy the LM2594 linear regulator, but I’m not sure…
And actually, I’m impressed with Coolterm, as it’s the only program I tried so far that gives you an error when you unplug the USB cable. All other programs just stop receiving answers. So: How does Coolterm find out, when the USB cable is unplugged?
moeterMemberSorry to hear that… but still, this also means, something else is going wrong: If the setup only works if we have the correct power sequence, then most likely we also need the correct power seqence when using the serial interface on the board directly. Am I correct?
As for the cmcgraths suggestion: I have to try on Unix/Linux, but Windows preserves the Handle when a FTDI device is disconnected, but obviously gets no more replies. This is actually okay behaviour. However, if we replug the device, we are still connected to the Null Handle, and even if we replug the device, you get no more answers. Im very interested in your solution, but I have my doubts if that would work on Windows (udev and Windows sounds, well, unlikely).
Actually it would be quite helpful to know how Coolterm notices the connection loss, as it’s the only Windows terminal program, that even takes notice of an unplugged FTDI device.
On another note: what would happen, if we just powered the 3.3V using an arbitrary 3.3V Pin and an external power supply? In my opinion it should either burn everything (or just the lm2594) down or power the logic part of the board, but not the output stage. alden, can you shed some light on this?
Thanks!
-
AuthorPosts