.u01 writer does not account for sequins #56
Comments
|
I posted a zip file that has stop, slow/fast and sequins in the PR pyembroidery thread. |
|
Found it, thanks. |
|
@wwderw The sequins file cannot have sequins in it. There's not a bit different from any other type. There cannot be sequin commands in that file. Can you load the .u01 file back up and have sequins in it, because I've mapped all those command sequences so much that I'm sure what they mean already to the point that they can't mean anything else. 1 11101001 0xE9 9 0 0 |
|
The book ends to that one section are trims 0xE7 is entirely trim. It can't really be anything else. Slow and fast worked fine and got mapped out. In the 15 color change file, it reuses the needles. Is that selectable? Can you select, say the 15th needle? That is after all kinda all I need. |
|
That file does have sequin info in it.
Yes on changing colors, that is user selected. |
|
I do know that when the sequin dispenser is active, jump commands tell the dispenser to drop sequin and to turn on the dispenser is like using C00, except it's S1. |
|
It might in theory be book ended with that trim but I don't see how that differentiates from well, trim. And those sequin stitch things are totally identical everybit with a stitches. It doesn't have any information here. Hm. Actually lemme check the header. |
|
Drat. It's exactly what I've properly already mapped. Just some zeros, some extends info, and the stitchcount. It doesn't seem to be storing this information in the file. |
|
I mean if it were throwing out jumps that I could at least work with but not only is that start trim just a trim, but the sequin ejects are just stitches not even jumps. Unless there's some other file in the same directory with some metadata to control this file I don't see how it can work. My only even somewhat working theory is that sequins are dropped by super-tiny stitches and book ended by the trims. Maybe the other things are off. How about a file that has actual trims? Maybe everybody else is wrong as to how those work? |
|
See about the 15 color one, it should have trim info between each color change. |
|
Hm. It interestingly never invokes command 7, except at the end before it jumps to the origin point again. |
|
The color changes don't trim and move ever, they use the color change command as a trim. |
|
See if that one helps you. |
|
Does this file have sequins in it? |
|
That doesn't even want to open up in any of my programs. |
|
Hm. How about? |
|
That one opened in my programs. I'll have to take it to the machine to see if it triggers any sequin "action" on the needle assignment list. Without having a PDF chart that shows when where it needs to be assigned, I have to see if it shows up automatically at the machine. I could assign it, but I need that info relayed to me via the pdf stitch file. I'll let you know if it triggers anything at the machine when I'm able to get down to the shop. |
|
Hm. What did you visualize the other one with? Some other program or something. Because in theory if such things don't visualize on the first go they gotta be something wrong. Though, the whole idea of the machine triggering the action and the sequins being kind of built into normal commands gives me some clear hope. Seems to suggest they aren't built into it overtly but rather are written in such a way as to trigger it. Which fits my current theory. That they are triggered by being inside a block with a single trim action, but no jump calls, after the call for trim, and then very tiny stitches triggering ejects. I assume this same stuff could happen generally and if it were the way my current wildguess of a theory has it, it would be kind of context dependent. |
The first one was actually using a native file, not the U?? file itself. The U?? do not generate the visual that the native file does. With regard to the 2nd file you sent me, even though it was 1 color, I was able to assign C01 (my sequin dispenser only runs with needle 1 is active) and then I was able to add S1 (much like if I was to do C01 and C00). However, no sequin drops. |
|
Thank you so much for this, @wwderw Theory C:
My new and current working theory given the impossibility of the file containing sequins is that the file doesn't contain sequins at all, not even semaphores. But rather your embroidery machine is just smart enough to perform a sort of pattern search and realize that if it's only stitching in this layer here but you ask for sequins it figures out from the pattern where those sequins should be. I included one with jumps rather than converting the sequin-jumps to stitches as Wilcom seems to do in case that makes the recognizing of patterns easier, though the file you gave me had them all as stitches. There is though, some chance a format like U02 might contain overt sequin information. |
|
Sequin jumps and sequins original both performed with sequin drops. Sequin jumps also spit out an extra sequin going from one row to the next, while sequins original did not. Typically the extra sequin was spit out closer to the previous row then it was toward the next row going to be stitched. Biggest difference is that the DST version (original) already recognized S1 and S0 in my needle assignments and that S0 is where we went from one row to the next, so it didn't produce that extra sequin. |
|
I take it from the omission that Sequin-Stitch produced no sequins? Or might have only done so between the rows? If so, it seems like the Sequins file you produced would actually not result in any sequins. If it's not interpolating the stitches and lost the jumps. That would seem like it must be the case if you try it on the machine. The DST version actually has sequins internally recognized in the format. The file itself declares where the sequins are rather than trying to figure out based on some guessing that the jumps are going to be sequins-ejects. The U01 doesn't have any sequins in the format. But rather takes your cue that that file should have sequins in it. Like tossing in a sequin mode command into a dst file without it, suddenly the jumps will become sequins. The ability to have sequin commands written into the files as jumps is already processed by the encoder. So if that's how U01 does sequins, perhaps more formats too, this will already be entirely supported. I'm adding in a contingency mode for the sequins so they will write act the way the user specifies but by default strip sequins turns sequins into jumps and that's what your machine needs to do that work. Given how this works, it will work for everybody already. I could add in something to let you convert single untrimmed jumps into sequence ejects. But, I'm not doing much work on the post processing. Though I did recently add a post processing function because I needed it to make those example files. |
|
That's quite possible (and I only say quite possible due to my shortcomings in knowledge base with the file internals). I have really only used DST files for sequins. The main advantage that I have with using the U?? file format is for slow/fast commands on regular embroidery. I don't have to "babysit" the machine accordingly. If all this is already in pyembroidery, I would say that it's good to go. Awesome! |
|
The slow and fast commands actually went through pretty well, working on being sure the encoder doesn't eat them accordingly. Given that, you likely could use both features in a U?? though you'd have to manually add some stops to switch to S0 and S1 but hopefully if this goes to plan all those features would work nicely together. If I had a sequin attachment I'd totes do the attached. And it's not really your fault on the .U01 the software out there is really quick to convert it to stitches rather than leaving it as jumps. It looks more proper as stitches but it's actually correct as jumps. Hence why I'm coding in an option for it. |
|
Okay, @wwderw It should be C00, stitch, stitch, command_unknown, stitch stitch, end. Crossing my fingers and super hoping for S1 and S0. |
|
I get 2 color blocks for all 3 of of those command files. Command 3 and it's unknown command shows up as "slow, jump". |
|
3 LJ Low Speed Jump Hm. Interesting. It matches the one manual quite well. How about these? Keep in mind
|
|
All mentioned below are either changes to what you had mentioned or I couldn't determine if you had them listed as unknown. 7 Trim, T2 |
|
For the Gp2 (Group 2) does the color change occur after the group command? Like it modified the following stitch or did it just sort of add an extra color change without using the following stitch? Without changing anything else? Best I can tell, the stuff in Group2 would have the S1 command. S0 commands if they exist. But, nothing gives any indication as to how these commands would be accessed so maybe throw some spaghetti at the wall and see what sticks? next-command uses the command space in the next command to try to get sub-commands out of the G2 whereas x-value and y-value try using that command. I included all the files, possible given the bitspace available. Odds are good one filetype doesn't do anything different, that encoding is a dud and none of them well. And my best guess is nextcommand is going to be the winner if there's a winner in the bunch. Mostly guessing if they added GP3,4 they might only have 32 added bits with with to work. |
|
The next commands seem to follow the schema above. The X values just do a color change where there is one stitch above Gp2 that is a different color (no function indication of a color change). Y values seem to be regular single color info to me. |
|
But nothing seems to have produced any different functions? The next commands did the same thing as the command itself indicated regardless of the location after a group command, so that's expected if it's a dud. The Y data seems to be nothing, which is expected if X is the meaningful value, or rather the data is encoded into X before the Y and the 0 in X made the Y value pointless. The X seems to be the only thing to do anything that affects the current element, which would make sense extra encoding used this data, so I guess that's the winner. Maybe I erred in thinking G2 was the interesting one. Assuming X values was the thing that did something here's G1 x values. |
|
Alternative maybe less fishing. According to the manuals I've been looking through, when you set those commands in the teaching mode it is literally editing the design. What happens if you edit a design to have sequins in it, then save it from memory to the USB. Can you edit them on the embroidery machine and get me a test file that way? |
|
Though on the, very above and beyond fishing expedition, g1-xvalues-65.u01 is the thing to check. If that guesses are right it might well be S1. Or g2, something with 65. Unless editing them could make them, in which case it's a moot point and I could just spelunk in the data. |
|
Hm. And where did you edit the sequin in there? Position 65 maybe. This file is wildly fascinating already. It is normal but appends something on the end that does seem to call the Group command. But, it looks like it might be doing postex form, like rather than edit the file in place, it's adding post-end data element that goes backwards and edits thing. |
|
Perhaps a file with more edits, or with fewer initial commands, or both. This, might actually be doable. |
|
Or an unedited version, dumped from the machine followed by an edited one. And then maybe a differently edited one. |
|
I'll see if I can get those various file formats edited and non edited from the machine this evening or tomorrow morning if all goes well. |
|
No problem. Heroic work though, certainly helped a bunch. I now at least see the reason for slow jump and fast jump, the slow and fast commands are themselves still a kind of stitch. The slow jump and fast jump commands are themselves a kind of jump. Unlike changing needles such things are done in drive mode. At a minimum most of this isn't just guessing anymore. I actually kinda grasp what's going on. At least enough to capture 99.99% of all commands in these file formats. Enough that I know I need to rewrite slow and fast slightly, because they stitch. I need to account for that or they will stitch each time you trigger them. Some of it has been hit or miss, but the hits are gold. Also, any clue what Afrm means. I'm pretty sure it's Sub End it's for Roll-to-Roll machines to stop with the needle in the down position. Maybe After Remove? I guess it doesn't matter, even knowing what it is, I likely won't hook it to any logic. Much like Rewind, Stop, though there I have no clue what that could mean. |
|
Let's see about these... |
|
And how about something where all the parts are known. Changing an initial c01 or c00 a different c value for instance? |
|
Edited or unedited? |
|
Both. Something super short though, like stitch experiment files with a command 0 (stitch) |
|
I'll just do some simple run stitch then and run one of them through the machine. I should have both of those later on this evening. |
|
The machine seems to add some data to the files so loading it and saving it back out produces a slightly different file. I'd need to see the file the machine made. And then the file with the change you made. So I can compare them. |
|
Though, also it might be just an illusion that anything is different at all. If you reload an edited file into a different location on the machine, does it maintain the edits you made? Because if it doesn't, we can just stop as there's nothing else in there. |
|
When I go to see about this latest one, I'll see. I've never had a cause load a file to the machine, make changes, reload to the CF card and then back to the machine. If I hadn't run the machine in a long time and it lost the file memory, I would just normally reload from the CF card, so I'm not sure how it does. I should know something later on this evening. |
|
It would then just be a matter for me to add an option or something to replace sequin mode commands in the format with STOP commands. Thus you'd know right where the relevant parts are and know to replace each STOP/STOP with S0/S1 and it would be the same different. It would make sequins there a breeze. Maybe something even a silly command like Afrm/ Sub End or the Group commands. Not like they are super-useful for anything else. And the Group commands might well show up in Teach for Color Change. |
|
Edited and Unedited Sequin Run and Stop.zip Alright, these should have 3 color block info. The 1st is to assign a needle, in my case C01 since that's the one that has sequins. Then for S1 to turn on the sequins and then C00 for a stop. The edited version does retain S1 and C00, but not C01. That has to be reassigned by user at the machine it appears. I would say because it's possible that it could be assigned to either C01 or C15 depending on the setup of the machine as sequin dispensers can be mounted on either end (or both for dual sequins, in order to swap sequins, I have to enter in a stop or manually stop the machine myself to get another sequin color/shape on the machine with one pattern). |
|
So get this. The files you edited on your machine to add sequins get recognized by Wilcom as having sequins. I've been staring at it in hex and it seems like it has a postfix log that edits the values after the fact, but with something that can read them I should be able to at least figure out what Wilcom find to be important and then get back to you with your machine, in due course. It somehow has some flags that mean something then point after log, to do what I think is Teach but in file format. But, it means .u01 absolutely and totally has sequins in them. And you've now provided me with file copies that demonstrate that. Giant ass thank you. Also, the files you sent me had the normal file and then the edited file and the one file was U00 rather than U01 do you have any idea what this means? Is there an actual distinction? Is it like the memory location you copy the file out of or something? I mean it doesn't seem like there's some kind of difference and some site online suggested it went up to T99 but how could that be if they are versions. And if they aren't versions, what the hell are they? |
If I recall correctly, the U00 files are post machine edited. As far as I'm concerned that has something to do with the machine having edited them and a way of distinguishing edited from the unedited (U01). I'm sure there is more to it then that, that's just from my layman's perspective. |
|
I heard about U02 files, so I'm not sure... but I think they are all the same thing. Not sure how to set that in pyembroidery without breaking things. Adding (".u00", "u01", ".u02") as ext is a breaking change that would actually cause requirements for code changes. |
|
Starting to figure out the Teach info. Might have some test files sometime soon. Though I won't really know what they do. Which seems weird. |
@wwderw Do you have a .u01 file with any sequin commands in it. I don't know any software that can make them but I know for a fact that the format has commands S0, S1, and SJ in it. I'd just need any file with these commands (.dst won't cut it, nothing can convert them into .u01 with sequins). Literally any .u?? with sequins, and I'll have the command numbers.
Also, could be done for SLOW and FAST.
The text was updated successfully, but these errors were encountered: